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Sir: 

We, John S. Brown, Diana Sinor, and Dilip J. Patel, hereby declare as 
follows: 

1 . We are the inventors of the subject matter claimed in the above- 
identified patent application. 

2. We have been informed that U.S. Patent Publication No. 
2003/0195780 to Arora et al. (hereinafter Arora) has been cited as prior art by the 
United States Patent and Trademark Office with respect to the above-identified 
patent application. We also have been informed that the earliest possible 
effective prior art date of Arora is no earlier than December 13, 2001. 
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3. This declaration is being submitted to establish conception and 
reduction to practice of the invention claimed in claims 1-16 and 18-21 of the 
above-identified application in the United States prior to December 13, 2001. 

4. Prior to December 13, 2001, we had conceived of and developed 
(i.e., reduced to practice) a working software program that met all of the 
limitations of claims 1-16 and 18-21 of our patent application, as more particularly 
detailed below. 

5. Exhibit A attached hereto is a copy of the Business Requirements 
for the project that resulted in the present invention. The date on the document 
has been redacted. However, it is prior to December 13, 2001 and accurately 
reflects the date of the document. 

6. Exhibit B attached hereto is the Program Functional Specification 
for the present invention prepared by one or more of the named inventors 
describing the relevant software as it existed on the date of the document 
preparation. The document includes several dates that have been redacted, 
including a creation date at the top of page 1 and then the date on which it was 
reviewed and approved by each of the eight people listed at the bottom of the 
last page. The dates on the document have been redacted. However, all dates 
are prior to December 13, 2001 and accurately reflect the true dates of the 
corresponding creation or review. 

7. Exhibit C attached hereto is the Program Functional Specification 
for the error correction facility portion for software that had to interface with the 
software of the present invention. Exhibit C. The dates on the document have 
been redacted. However, all dates on the document, including the date listed 
under "Last Changed By" are prior to December 1 3, 2001 . Under the heading 
"Capitalizations, including Posting to WIP", you will find a list of tax location fields. 
These fields were added to the facility as a result of the new errors produced by 
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the tax location program that had to be corrected. Similar fields can be found in 
the "Transfers Screen" section which follows the capitalization section. 

8. A program in accordance with the Program Functional Specification 
(Exhibit A) was coded immediately after the document was completed and the 
software passed testing shortly thereafter. All of these events occurred prior to 
December 13, 2001. 

9. Exhibit D attached hereto is a memorandum prepared by co- 
inventors Diana Sinor (maiden name Diana Hill) and John S. (Sim) Brown 
concerning the development of the invention disclosed and claimed in the above- 
identified patent application. The dates appearing on the original of this 
document have been redacted from the copy attached hereto. However, every 
redacted date is prior to December 13, 2001. Software in accordance with the 
invention claimed in this application had been developed and deployed for its 
intended purpose prior to the preparation of this document. 

10. The present application discloses a method and apparatus for 
determining the tax location of a capitalized fixed asset. In particular, in 
accordance with one embodiment, when a transaction concerning a particular 
asset is recorded, the transaction record is provided to the tax location finder 
module. The tax location finder module runs through a hierarchical sequence of 
queries of the information assigned to the assert. In each query, the tax location 
finder module checks to determine if the data assigned to the asset meets a set 
of criteria that helps indicate a particular routine (or audits) that will probably be 
able to derive the tax location of the asset. Such criteria typically might comprise 
conditions that indicate the type of asset (e.g., manufacturing equipment/real 
estate/furniture), the name of the assets use (e.g., internal/customer- 
site/loaner/vendor-site), and/or the building, employee, or cost center to which 
the asset is assigned. If the data associated with the asset meets the set of 
criteria for a particular audit, then that audit routine will be called. If the asset 
does not meet the query criteria for an audit, then the software will continue on to 
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the next sequential query until it encounters a query whose criteria it meets. 
Each audit is customized to the asset or transaction qualities that caused it to 
meet the criteria for calling that audit. The called audit attempts to derive the 
location of the asset. If the audit routine discover sufficient data to derive a tax 
jurisdiction code, then the derived tax jurisdiction code is passed back. If not, the 
transaction record is sent to an error correction facility where it may be manually 
researched and corrected. One or more of the audit routines may be designed to 
return the record transaction back to the hierarchy of queries if the audit fails for 
certain reasons. 

1 1 . We conceived and reduced to practice the invention claimed in 
claims 1-21 of the above-identified patent application prior to December 13, 
2001 . All of Exhibits A, B, C, and D accurately reflect or discuss software that 
had been actually developed and written prior to December 13, 2001. 

12. The attached claim table maps the claims element-by-element to 
the evidence submitted herewith. 



CLAIM TABLE 



Claim Recitation 


Exemplary Corresponding 
Disclosures 
in Exhibits 


1 . A method of tracking the 
location of capitalized fixed assets for 
tax and/or insurance reporting 
purposes, said method comprising 
the steps of: 


Exhibit D, page 2, lines 10-16. 


(1) detecting when a 
capitalized fixed asset is involved in a 
transaction; 


Exhibit D, page 2, lines 19-20. 


(2) responsive to such a 
detection in step (1), running data for 
said asset through a plurality of 
queries, each query designed to 
determine if said asset meets a set of 
criteria indicative of a category of how 
a location of said asset for tax and/or 


Exhibit D, page 2, lines 19-22. 
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insurance reporting purposes may be 
determined; 




(3) if, in step (2), said asset 
meets said set of criteria 
corresponding to one of said queries, 
running data corresponding to said 
asset through an audit customized to 
said corresponding category to 
determine a location of said asset for 
tax and/or insurance reporting 
purposes; 


Exhibit D, page 2, lines 23-25. 


(4) if, in step (3), a location is 
determined, assigning said 
determined location to said asset for 
tax and/or insurance reporting 
purposes; 


Exhibit D, page 2, lines 23-25. 


(5) if, in step (3), a location for 
tax and/or insurance reporting 
purposes is not determined issuing 
an error notification; and 


We were unable to readily find actual 
error codes and descriptions directly 
demonstrating this claim feature. 
However, it was incorporated in the 
inventive software as reduced to practice 
and actually implemented prior to 
December 31 , 2001 . Exhibit C is indirect 
evidence of this; particularly the sections 
entitled "Capitalization including Postings 
to WIP" and "Transfer Screen". As 
described above in paragraph 7, these 
sections of Exhibit C reflect changes that 
were made to software that interfaced 
with the inventive software in order to be 
compatible with error codes generated 
by the present invention in accordance 
with this feature of the invention. 


(6) if, in step (2), if said data for 
said asset does not meet said criteria 
of any of queries, issuing an error 
notification. 


Exhibit D, page 2, lines 23-25. 






2. The method of claim 1 
wherein, in step (2), each of said sets 
of criteria comprises at least one 
criterion to which said data for said 
asset must match. 


Exhibit D, page 2, lines 20-21. 






3. The method of claim 2 


Exhibit D, page 2, lines 21-22. 



Appln. No. 10/086,244 
Page 6 



wherein, in step (2), said data for said 
asset is run through said plurality of 
queries hierarchically, wherein, when 
said asset meets said set of criteria of 
a particular query, said asset data is 
not run through any queries ordered 
lower in said hierarchy. 








4. The method of claim 3 wherein 
said transaction comprises a transfer 
or capitalization. 


Exhibit D, page 2, lines 14-16. 






5. The method of claim 3 wherein 
said error notification issued in step 
(5) indicates that the asset met said 
set of criteria corresponding to one of 
said categories, but was not assigned 
a location for tax and/or insurance 
reporting purposes. 


See claim 1, step (5) discussion in this 
table. 






6. The method of claim 5 wherein 
said error notification issued in step 
(5) further indicates which of said at 
least one criterion caused said error. 


See claim 1, step (5) discussion in this 
table. 






7. The method of claim 5 wherein 
said error notification issued in step 
(6) indicates that said asset data did 
not meet said criteria corresponding 
to any category. 


Exhibit D, page 2, lines 23-25. 






8. A computer readable product 
embodied on computer readable 
media readable by a computing 
device for tracking the location of 
capitalized fixed assets for tax and/or 
insurance reporting purposes, said 
product comprising computer 
executable instructions for: 


Exhibit D, page 2, lines 10-16. 


(1) interfacing with external 
software to become aware of when a 
capitalized fixed asset is involved in a 
transaction; 


Exhibit D, page 2, lines 19-20. 


(2) responsive to such a 
detection in step (1), accessing data 


Exhibit D, page 2, lines 19-22. 
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for said asset and running said data 
through a plurality of queries, each 
query designed to determine if said 
asset meets a set of criteria indicative 
of a category of how a location of said 
asset for tax and/or insurance 
reporting purposes may be 
determined; 




(3) if, in step (2), said asset 
meets said set of criteria 
corresponding to one of said queries, 
running data corresponding to said 
asset through an audit customized to 
said corresponding category to 
determine a location of said assetjor 
tax and/or insurance reporting 
purposes; 


Exhibit D, page 2, lines 23-25. 


(4) if, in step (3) a location is 
determined, assigning said 
determined location to said asset for 
tax and/or insurance reporting 
purposes; 


Exhibit D, page 2, lines 23-25. 


(5) if, in step (3), a location is 
not determined issuing an error 
notification; and 




(6) if, in step (2), if said data for 
said asset does not meet said criteria 
of any of queries, issuing an error 
notification. 


Exhibit D, page 2, lines 23-25. 






9. The computer readable 
product of claim 8 wherein instruction 
(4) further comprises instructions for 
transmitting said determined location 
for tax and/or insurance reporting 
purposes to said external software. 


Exhibit B, page 1, third paragraph, 
beginning with "Based on Input fields, 
location ... ". 






10. The computer readable 
product of claim 8 wherein, in 
instruction (2), each of said queries 
comprises at least one criterion to 
which said data for said asset must 
match. 


Exhibit D, page 2, lines 20-21. 






1 1 . The computer readable 


Exhibit D, page 2, lines 21-22. 
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product of claim 1 0 wherein, in 
instruction (2), said data for said 
asset is run through said plurality of 
queries hierarchically, wherein, when 
said asset meets set of criteria of a 
particular query, said asset data is 
not run through any queries ordered 
lower in said hierarchy. 








12. The computer readable 
product of claim 1 1 wherein said 
transaction comprises a transfer or 
capitalization. 


Exhibit D, page 2, lines 14-16. 






1 3. The computer readable 
product of claim 1 1 wherein said error 
notification issued by instruction (5) 
indicates that the asset met said set 
of criteria corresponding to one of 
said categories, but was not assigned 
a location for tax and/or insurance 
reporting purposes. 


See claim 1, step (5) discussion in this 
table. 






14. The computer readable 
product of claim 13 wherein said error 
notification issued by instruction (5) 
further indicates which of said at least 
one criterion caused said error. 


See claim 1 , step (5) discussion in this 
table. 






15. The computer readable 
product of claim 13 wherein said error 
notification issued by instruction (6) 
indicates that said asset did not meet 
said criteria corresponding to any 
category. 


Exhibit D, page 2, lines 22-25. 






16. The computer readable 
product of claim 8 wherein instruction 
(1) comprises detecting a call from 
said external software. 


Exhibit B, page 2, third paragraph, 
beginning with "Based on Input fields, 
location ... ". 






1 8. The computer readable 
product of claim 8 wherein instruction 
(3) comprises accessing said data 
corresponding to said asset from at 


Exhibit D, page 2, lines 14-20. 
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least one of a database and a 
transaction record received from said 
external software. 








1 9. A computer system having at 
least one memory for storing data 


Inherent 


and at least one central 
processing unit for executing 
instructions, 


Inherent 


said memory storing at least 
one database containing data about a 
plurality of capitalized fixed assets, 


Exhibit B, See, e.g., page 3, line 1, under 
heading "Interim Location Derivation 
Process" line that reads "Read 
Warehouse Owner Table by Warehouse 
number and Country Code as key." 


said central processing unit 
adapted to track the location of 
capitalized fixed assets for tax and/or 
insurance reporting purposes, 


Exhibit D, page 2, lines 10-16. 


said computer system 
comprising means for recording 
transactions relating to capitalized 
fixed assets, said system further 
comprising: 


Exhibit D, page 2, lines 19-20. 


means for interfacing with 
external software to become aware of 
when a capitalized fixed asset is 
involved in a transaction; 


Exhibit D, page 2, lines 19-20. 


means responsive to said 
detection for accessing data for said 
asset and running said data through a 
plurality of queries, each query 
designed to determine if said asset 
meets a set of criteria indicative of a 
category of how a location of said 
asset for tax and/or insurance 
reporting purposes may be 
determined; 


Exhibit D, page 2, lines 19-22. 


means for running data 
corresponding to said asset through 
an audit customized to said 
corresponding category to determine 
a location of said assetfor tax and/or 
insurance reporting purposes, if said 
asset meets said set of criteria 
corresponding to one of said queries; 


Exhibit D, page 2, lines 23-25. 
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means for assigning said 
determined location to said asset for 
tax and/or insurance reporting 
purposes and transmitting said 
determined location to said controller 
software, if a location is determined; 


Exhibit D, page 2, lines 23-25. 


means for issuing an error 
notification, if a location is not 
determined; and 


Exhibit D, page 2, lines 23-25. 


means for issuing an error 
notification if an asset type is not 
determined for said asset. 


Exhibit D, page 2, lines 23-25. 






20. The computer system of claim 
19 wherein each of said queries 
comprises at least one criterion to 
which said data for said asset must 
match. 


Exhibit D, page 2, line 21. 






21 . The computer system of claim 
20 wherein said data for said asset is 
run through said plurality of queries 
hierarchically, wherein, when said 
asset meets set of criteria of a 
particular query, said asset data is 
not run through any queries ordered 
lower in said hierarchy. 


Exhibit D, page 2, lines 21-22. 
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13. As the persons signing below, we each hereby declare that all 
statements made herein of my own knowledge are true and that all sfaten rente 
made on information and belief are believed to be true; and further that these 
statements were made with the knowledge that willful false statements and the 
like so made are punishable by fine or imprisonment or both, under Section 1001 
of Title 18 of the United States Code, and that such willful statements may 
jeopardize the validity of the application or any patent issued thereon. 



Date lohn S hi > n 





i; e 



Diana Si nor 



MHR-E6-E009(THU) 11: ai CflPITRL OFFICE SUPPLy 



(FRX)919H310008 



P. 002/OOE 
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1 3, As the persons signing below, we each hereby declare that all 
statements made herein of my own knowledge are true and that all statements 
made on information and belief are believed to be true; and further that these 
statements were made with the knowledge that willful false statements and the 
like so made are punishable by fine or imprisonment or both, under Section 1001 
of Title 18 of the United States Code, and that such willful statements may 
jeopardize the validity of the application or any patent issued thereon. 



□ate John S. Brown 



Date ~" DilipJ. Patel 
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TAX LOCATION ASSIGNMENT REQUIREMENTS 



Tax Location Assignment 
Conirollers\Capitalizalions 



Contact Listing 

• PI: Sim Brown 

• SI: Dilip Patel 

• AD: 



I. OVERVIEW 

Determining an asset's location probably seems like a simple and rather insignificant matter on the surface. 
After all, it should be as easy as asking the asset owner to report the asset's location at the time of its purchase and 
capitalization or transfer. However, IBM's asset tracking systems have traditionally been maintained separately 
from their requisition, capitalization and transfer functions. This separation of functions has historically prevented 
the requester from identifying the asset's intended owner much less its final destination. As a result of this system 
limitation, the asset system architects have been forced to resort to a rather convoluted and confusing series of 
defaults to determine an asset's location. These defaults, although fairly comprehensive, have often resulted in 
invalid asset location assignments. 

The significance of these erroneous assignments is not apparent if you consider the situation from a purely 
accounting perspective. After all, the most important piece of inventory information is the asset owner's serial 
number not the physical location of the asset. However, the asset's location is easily the most significant piece of 
tax information maintained within our asset system. The asset's location is used when calculating State Income Tax, 
Personal Property Tax, Sales Tax, Use Tax and various franchise taxes. Since the right to tax citizens within the US 
is a right that was originally given exclusively to the states and municipalities, our tax law varies extensively from 
state to state, even from city to city. An erroneous tax location assignment can easily result in the overpayment of 
any number of taxes. As such, it is crucial that the next release of our asset system include a commitment to 
deriving and maintaining the highest quality of location information available given the limitations of our requisition 
systems. 

IBM's requisition systems and methodologies vary depending on the type of equipment that is being ordered 
and the division placing the order. These requisition systems are not standardized especially when considering the 
type of information the requesters are asked to provide. Some requisition tools require the requester to enter an IBM 
customer number and very little additional information. Other tools ask the requester to enter ship to information 
and their employee serial number as well as their IBM customer number. In some cases, the IBM customer number 
is not required at all. Instead, the requisition tool relies on the requester to enter shipping and billing account 
information. Due to the variety information being solicited at the time the order is placed it is impossible to develop 
a single, comprehensive approach to tax location assignment. Instead the challenge has been to derive the tax 



location based on the most reliable piece of location information provided on the record. 

In response to this challenge, the current system architects focused their efforts on developing a derivation 
process based on direct asset owner inr^ut rather than attempting to derive the asset's location during the 
capitalization process. Since this input could not be solicited at the point of requisition, the developers designed a 
back end process based on asset owner input from the Property Control Facility (PCF). The Property Control 
Facility's functionality is based almost entirely on asset owner input. As such, requesting location information from 
the asset owners was a simple matter of adding a notifier to the system. After an asset is capitalized and reported to 
the Property Control Facility, a notifier is sent to the asset owner soliciting information regarding the asset's 
location. Once the asset owner inputs the location information, the updated information is loaded to the PCF 
Register Table. This table is the primary source of input for the current tax location derivation program (CR07). 

From a purely theoretical stand point, the tax location methodology laid out by the previous system architects 
should result in the most reliable tax location assignment available because it is based on the asset owner's input. In 
practice, though, this strategy has proven to be unreliable and inconsistent. There are a number of reasons why the 
current tax location strategy has not delivered the expected results. These reasons range from timing variances to 
invalid asset owner assignments. However, the single most pervasive problem in obtaining a valid tax location 
using the current tax location assignment strategy is simply lack of asset owner input. In short, when the asset 
owners receive notifiers from the Property Control Facility asking for location information, the majority of them 
simply do not respond. When the requested location information updates are not made, the location information 
must be derived. 

The current tax location derivation program (CR07) is based on a hierarchy of defaults. This default tax 
location information is prioritized in order of its perceived reliability. The default hierarchy is applied to all assets 
regardless of asset type or capitalization source. Under this system, for example, facility number is considered the 
most reliable piece of tax location information for everything from buildings to data processing equipment. On its 
face, this assumption does not seem problematic. However, when considering the various tracking and 
capitalization methodologies used for buildings versus data processing equipment, it is obvious that assigning a 
single tax location methodology to be applied to all types of equipment will invariably result in erroneous tax 
location assignments. 

Faulty default logic is not the only problem associated with the current tax location derivation program. In 
addition to establishing a single hierarchy of location information for all asset types, the program also bases this 
hierarchy on the false assumption that the Property Control Facility is the most reliable source of location 
information for all types of equipment. Although a rational argument could be made to support this assumption for 
most types of equipment, data processing equipment, specifically, has traditionally been tracked on the AAS asset 
management system. The AAS asset management system tracks all data processing equipment ordered internally. 
This system is used for property control, but its primary function is parts maintenance, warehouse administration 
and account billing. The additional functionality provided by the AAS asset management system is critical to the 
business; as such, updating asset information on AAS is often more important to IBM's internal customers than 
updating the same information on PCF. Considering the customers' priorities, an argument could easily be made 
that the AAS asset management system is likely to have the most updated location information on internally 
procured data processing equipment. Since the current tax location derivation program places more emphasis on 
information from the Property Control Facility than AAS, it is clear that the tax location assignments of internally 
procured data processing equipment are questionable under the existing methodology. 

In addition to the questionable tax location assignment of internally procured data processing equipment, the 
current tax location derivation program has another, more significant flaw. The program's assumption that the 
Property Control Facility is the most reliable source of location information is based on the invalid conclusion that 
asset owner's usually respond to the system notifier requesting location information. History has shown that this 
conclusion is false. The majority of asset owners do not respond to the system notifier requesting location 
information, as a result the Property Control Facility is never updated with location information from the asset 
owner. Without updated information from the Property Control Facility, the fields on the PCF Register that 
generate the tax location assignment remain blank. When the current tax location derivation program encounters 
blanks in these key fields, it often resorts to assigning the tax location based on a default location assigned at the 



division level. This default division logic does not take into consideration any of the tax location information that 
may have been available at the time of capitalization. As a result, the existing tax location methodology's reliance 
on' information from the Property Control Facility often results in a default tax location assignment that is less 
accurate than the tax location that could have been established at the point of capitalization. 

Realizing that the current tax location methodology does not take advantage of all of the information available 
at the point of capitalization, the system architects have proposed an alternate tax location strategy to optimize the 
use of this information. The strategy is fairly simple. In short, the system architects are proposing that the tax 
location be derived at the point of capitalization, establishing the most reliable default value available. After the 
asset is capitalized and the default tax location is established, the asset owner will still have the ability to update the 
location information if they choose to. Moving the default tax location derivation process to the initial capitalization 
phase allows the system architects to customize the default assignment process for different types of equipment from 
different capitalization sources. By customizing the tax location derivation strategy by asset type and capitalization 
source, the system architects afford the tax customers the ability to assess what is the most valuable piece of tax 
location information available and base the default assignment on that information. As a result, the default tax 
location assignment is based on the highest quality of tax location information available at the point of 
capitalization, eliminating the need for generic default logic based on the asset's division. 

In addition to the elimination of division level default logic, the introduction of this new tax location 
methodology will insure that every asset has a valid tax location assigned to it at the point of capitalization. This 
assurance may seem an obvious result of any well developed tax location strategy. However, the current tax 
location strategy was unable to achieve one hundred percent tax location assignment even considering the six levels 
of defaults it employed. Its failure to meet this goal resulted in approximately two thousand assets annually that had 
to be manually assigned a tax location at year end. This manual assignment process was both time consuming and 
somewhat unreliable. With the adoption of the new tax location methodology this tax exposure will be resolved and 
the need to establish the most reliable default tax location available will be addressed. 



II. DATA PROCESSING EQUIPMENT 

A. INTERNALLY MANUFACTURED DATA PROCESSING EQUIPMENT 
1. CAPITALIZATIONS 

There are four different capitalization sources for internally manufactured dataprocessing equipment - ICF, FDS, 
WIP and MTC. Each of these sources provides unique location information at the point of requisition. ICF and 
FDS, for example, rely on customer number information for location derivation. While WIP and MTC 
capitalizations provide IBM employee serial number information that could be used for location derivation. When 
presented with these varied pieces of location information, our panel of tax representatives selected customer 
number as the most reliable piece of location information for 
capitalizations of data processing equipment. 

a.TAX LOCATION DERIVATION STRATEGY - OVERVIEW 

The tax location derivation strategy for internally manufactured data processing equipment is fairly simple. 
Based on the IBM customer number provided on the inbound capitalization record, the state/city/county code 
should be extracted from the S A ADB .MINICMR Table. This code will need to be converted to the associated 
TAXWARE code prior to posting to the Asset Master Record. The SAP Asset System will convert the 
state/city/county code to the TAXWARE code by making a call against the TAXCALC to TAXWARE mapping 
table (see SYSTEM REQUIREMENTS for specific information on this table). 



The tax location derivation strategy as outlined above is based on the assumption that the SAADB .MINICMR 



table can be loaded on to theSAP Asset System. If this table proves to be too large to load, a secondary strategy 
might be considered. This alternative tax location derivation strategy would still be based on the IBM customer 
number provided on the inbound capitalization record. However, rather than extracting the state/city/county code 
from the SAADB.MINICMR Table,the TAXWARE code would be retrieved directly from the Market Place 
Profile database (see EXTERNAL DEPENDENCIES for specific information on this database). 

b. EXTERNAL DEPENDENCIES 

i. MARKET PLACE PROFILE (MPP) 

The goal of the Market Place Profile Project is to create a worldwide customer database that includes all 
IBM internal and external customers currently assigned an IBM customer number. The database is expected to 
house customer information similar to the information currently maintained on the US SAADB.MINICMR Table 
with one 

significant difference. The MPP database will list the tax location code used by the TAXWARE program whereas 
the SAADB.MINICMR's "locationcode" field contains the state/city/county code used by the TAXCALC 
program. 

As part of this project all of IBM's current customers will receive a new customer number. However, the MPP 
database will track both the new customer number and the original customer number from the SAADB.MINICMR 
Table. This feature of the MPP database will allow the system architects to build a mapping table between the 
current state/city/county code and the TAXWARE code by joining on the original IBM customer number. 

, This TAXCALC to TAXWARE mapping table is essential for yearend conversion of the US assets' tax 
location information. This tax location infprmation is maintained on the SAADB.TLOCATION_W table and will 
need to be loaded on the Asset Master Record of every US asset that is converted. 

In addition to conversion concerns, the TAXCALC to TAXWARE mapping table will be needed to derive the 
tax location code for internally manufactured data processing equipment. The strategy for deriving 
the tax location of this type of equipment involves extracting address information and the current state/city/county 
code from the SAADB.MINICMR table. Prior to posting the tax location code to theAsset Master Record, the 
state/city/county code will need to be converted to the TAXWARE code. 

c. SYSTEM REQUIREMENTS 

i. TAXCALC TO TAXWARE MAPPING TABLE 

As described above, the TAXCALC to TAXWARE Table is needed to convert the state/city/county code 
housed on the current SAADB.MINICMR Table into a TAXWARE code that will be maintained on the Asset 
Master Record. 

EXAMPLE TABLE: 

[Original Customer Number |MPP Customer Number |State/City/County Code |TAXWARE Code 
|46 19803 |4567890 ' |907865123 ~~ |050130040 " 

(6292159 Hl234567 |05 1234890 |l01210080 

|00 11612 [9876543 [564312089 [040371900 



FIELD DERIVATION MATRIX: 



[Field Name 


|Derivation 


|Original Customer Number 


|Based on Feeder Input Record 


[MPP Customer Number 


|Derived from the MPP Table; Based on the Original Customer Number 


|State/City/County Code 


|Derived from the SAADB.MiNlCMR Table; Field Name = Location Code 


ITAXWARE Code 


|Derived for the MPP Table; Based on the Original Customer Number 



OPEN ISSUE: 

In cases where an asset is being maintained at a location not currently listed on the SAADB.MiNlCMR 
Table, the SAP Administration Team will need a contact in the SUT Department whose has access to the on-line 
TAXWARE program. The SAP Administration Team will provide the SUT Department with the new address and it 
will be the SUT Department's responsibility to provide the correct tax location code. The representative from the 
SUT Department will need to assign both a state/city/county code and an associated TAXWARE code to the new 
address so that the SAP Administration Team can add the necessary entry to the TAXCALC to TAXWARE 
Mapping Table. 

ii. CUSTOMER NUMBER TABLE 

The Customer Number Table is necessary in order to derive thebuilding number associated with the asset's 
IBM internal customer number. This building number assignment is required for all IBM internal assets in order to 
satisfy insurance and federal income tax reporting requirements. 

EXAMPLE TABLE: 

|Country ^Original Customer Number [Responsible Cost Center [Building Number |TAXWARE Code 
[US "[4679803 ~~~~ |RKA [pLDO'Jol [^(H3o1mT 

|US J6292159 ]9FP ~ ~[pTb861 [101210080 

[US |001 1612 " [79Q ~ [RPL676 [040371900 



FIELD DERIVATION MATRIX: 



[Field Name 


Derivation 


[Country 


Hardcoded to 'US" 


Original 

|Customer Number- 


Based on Feeder Input Record 


Responsible Cost 
Center 


Derived from the SAADB.MiNlCMR Table; Field Name = Dept 


Building Number 


*Input by SAP Table Administrator; Input = Work Location Concatenated with the RE/SO 
Building Number 


(TAXWARE Code [Extract the State/City/County Code from the SAADB.MiNlCMR Table; Field Name = Location 
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Code. Use this value to map to the TAXWARE Code based on the TAXCALC to TAXWARE 
Mapping Table. 



OPEN ISSUE: 

The RE/SO Building Number (ex. 676) is currently maintained in any one of four address fields included on 
the SAADB.MINICMR table. Since the building information is not housed in a standard location on the table, it 
cannot be automatically derived. As such, the SAP Administration Team must look up each new customer number 
on the SAADB.MINICMR to determine the RE/SO Building Number. Once they have identified the RE/SO 
Building Number, they must access Worldwide RE/SO Building Database (see EXTERNAL DEPENDENCIES for 
Transfers) to locate the associated work location. This process is extremely manual, but the SAP Administration 
Team has agreed to accept this responsibility if an automated solution cannot be found. In order to facilitate this 
manual process, the SAP Administration Team has requested that the spool list for the automated job that loads the 
Customer Number Table (currently job # BW07) be updated to produce a listing of all new customer numbers added 
during the load. The SAP Table Administrator will use this listing to identify which customer numbers have been 
added so that their building information can be updated in a timely manner. 

2. TRANSFERS 

There are three different transfer feeders for internally manufactured data 
processing equipment - PCF, AST, and MTT. The tax location information included on both PCF and MTT varies 
with each transfer. In some cases, the tax location information may include customer number, building number 
and/or IBM employee 

serial number. Because the tax location information is not consistent our panel of tax representatives selected a 
tiered tax location strategy. This tax location strategy is designed to look for customer number updates as the 
primary source 

for tax location derivation and use IBM employee serial number as a secondarysource. 

As for AST transfers, these transfers are keyed by changes in the AAS Status Code. 
These transfers are limited to specific changes in the AAS Status Code that indicate that the equipment has been 
returned to the plant. When such a change is reported by the AST feed, a tax location transfer is initiated to reflect 
the 

asset's new location at the plant. 



a.TAX LOCATION DERIVATION STRATEGY - OVERVIEW 

The first tier of the transfer tax location strategy for internally manufactured data processing equipment mirrors 
the tax location strategy for capitalizations. Based on the IBM customer number associated with the asset's new 
location, 

the tax location is derived by extracting the state/city/county code from the SAADB.MINICMR Table. This 
state/city/county code is then mapped to the TAXWARE code it is paired with on the TAXCALC to TAXWARE 
Mapping Table. 

This TAXWARE code is posted to the Asset Master Record overwriting the previous TAXWARE code that was 
assigned to the asset. In addition to deriving the TAXWARE code associated with asset's new location, the building 
number of that new location must also be derived. Again, the derivation strategy for IBM building assignment is the 
same process used for 

establishing the original IBM building number at the point of capitalization. The IBM customer number on the 
transfer input record is used to make a call against the Customer Number Table. This table contains a mapping of 
the 

original IBM Customer Number to the IBM building number. The new building number is extracted from the table 
and posted to the Asset Master Record. The second tier of the tax location strategy for transfers of internally 
manufactured data processing equipment is based on the IBM employee serial number the asset is being transferred 



to. The IBM employee serial number is extracted from the transfer input record. This serial number is used to make 
a call against the Worldwide RE/SO Building Database (see EXTERNAL DEPENDENCIES for 

specific information). The database provides both the TAXWARE code and the IBM building number that are 
associated with the base 

IBM employee serial number. This information is then posted to the Asset Master Record overwriting the outdated 
tax location code and building number. Finally, there is a unique tax location strategy associated with AAS Status 
Code changes reported in the AST feed. This feed tracks changes in the AAS Status and Function Code Table from 
one month to the next. One of the fields maintained on this table is the AAS Status Code. This code identifies 
changes 

in the asset's use as well as its location. The updated AST requirements include a change to the current AST feed 
logic. The new logic that will be employed in SAP Release 2.2 requires the feed to report changes in the AAS 
Status Codes for 

all assets listed on the AAS Status and Function Code Table. When an asset's AAS Status Code changes to '80', 
'82', '83', or '84', that signifies that the asset is no longer in use and it has been returned to the plant. These returns 
are 

eligible for both PPT and SUT exemptions; as such, they need to be identified and reported in the outbound PPT and 
SUT feeds. The following logic is employed to uniquely identify these assets: 

If an asset's AAS Status Code changes to an '80 ', '82 ', '83 ', or '84 ' , the PCF Usage 
Code on the Asset Master Record should be updated to a '15' to reflect that the 
asset is now in storage. In addition, the AAS Status Code on the Asset Master 
Record should be overwritten with the new status of '8x '. Finally, the tax 
location of the asset should be amended to identify its new location at the 
plant. In order to update the tax location,' the following derivation process 
must be used: extract the ' PLANT _OF_CONTROL 'from the SAADB. STA TJFUNC 
Table; use this value to make a call against the Plant of Control Table (see 
SYSTEM REQUIREMENTS for a complete description of this table); from the 
Plant of Control Table derive the IBM building number and the TAXWARE code 
associated with the plant location; post the updated TAXWARE code and IBM 
building number to the Asset Master Record. 

b. EXTERNAL DEPENDENCIES 

i. WORLDWIDE RE/SO BUILDING DATABASE 

This database is a listing owned by RE/SO and maintained on Lotus Notes. It contains a record of all inactive 
and active buildings owned or leased by IBM on a worldwide basis. The database houses a wide variety of 
information on each building including the building's address, the building's use, the work location of the building, 
whether it is owned or leased, lease information for leased locations, the responsible division, the inactive or active 
status of the building as well as the date the status of the building changed. In addition to maintaining this 
information, the owner of the database, John E. Miller in RE/SO, has agreed to add a new field to the database that 
will house the~TAXWARE code associated with the location of each building. This agreement by the database 
owner is critical to our tax location strategy. Every type of asset that bases its tax location derivation on the IBM 
employee serial number will be making a call against Worldwide RE/SO Building Database to retrieve the IBM 
building number and the associated TAXWARE code. 



ii.IBM SPACE SUITE - RE/SO SPACE TRACKING DATABASE 

In addition to its Worldwide Building Database, the RE/SO organization is in the process of mapping the 
physical location of every IBM employee to an existing IBM facility. This information is currently being 
maintained on an MVS/DB2 platform on a site by site basis. The database owner, John E..Miller, has indicated that 
the employee information will be added to the existing Worldwide RE/SO Building Database on Lotus Notes by 
yearend 2000. At this time, he suggested that all of the Americas would be on this integrated database and the 
EMEA would be migrated to this platform sometime in 2001. The timing of inclusion of the IBM employee 
location information is critical to our project. Since our strategy is predicated on the ability to match the IBM 



employee serial number on the input records against the Worldwide RE/SO Building Database, RE/SO's failure to 
integrate the IBM employee information into their database by yearend 2000 would invalidate 90 percent of our tax 
location derivation efforts. Because of our obvious dependency on RE/SO's efforts, the SAP 
Administration Team's Management has asked that the SI Team obtain a Document of Understanding from the 
RE/SO management in support of our project. 

iii.MARKET PLACE PROFILE (MPP) 

As with capitalization of internally manufactured data processing equipment, the tax location derivation 
strategy for transfers of this type of equipment is dependent upon the Market Place Profile Worldwide Customer 
Database Project. The dependency upon this external project is explained in detail under the CAPITALIZATIONS - 
EXTERNAL DEPENDENCIES 
portion of this sub topic. 

c. SYSTEM REQUIREMENTS 

i. PLANT OF CONTROL TABLE 

The Plant of Control Table is required in order to derive the tax location 
of internally manufactured equipment that has been returned to the plant. This table uses the 
'PLANT_OF_CONTROL' value from the SAADB.STATJFUNC Table to derive the associated IBM building 
number and TAXWARE code. 



Country [Plant [Name : Building TAXvV A RE Cod7 

r[s~an LDOf '« ■ : 
[Us" N8 |?al. ^riRPUC" 'i"jo:,,1QOO 
'US |992~~ [End icon 7L EMl" [201340987 



FIELD DERIVATION MATRIX: 



■Field Name 


Derivation i 


[Country 


Hardcocled to 'US' 


(Plant 


Derived from SAADB.STAT_FUNC Table where the Field Name = PLANT OF CONTROL 


[Name 


Input by SAP Table Administrator 


[Building 


lira i' b\ S \P Table \d nmismrm based on contact with tne PPT Department . 


TAXWARE 
Code 


Input by Table Administrator based on the Building Number by referencing the Worldwide 
RE SO Building Database 



OPEN ISSUE: 

The Plant of Control Table is being maintained as part of the current SAP Release. This table contains 
basically the same information as the information that will be required in SAP Release 2.2. The two major 
exceptions are that the table includes facility number rather than building number and the state/city/county code 



rather than the TAXWARE 

code. This information will need to be converted to facilitate the initial set up of the Plant of Control Table. Since 
the current table only has eight entries, the initial set up of the Plant of Control Table will require only a minimal 
effort. It is mentioned here for the sake of completeness. 

ii. TAXCALC TO TAXWARE MAPPING TABLE 

The requirements for this table are described in full under the SYSTEM REQUIREMENTS section of the 
CAPITALIZATIONS portion of this sub section. 

iii. CUSTOMER NUMBER TABLE 

The requirements for this table are described in full under the SYSTEM REQUIREMENTS section of the 
CAPITALIZATIONS portion of this sub section. 

B...EXTERNALLY MANUFACTURED DATA PROCESSING EQUIPMENT 
1. CAPITALIZATIONS 

There are three capitalization sources of externally manufactured data processing equipment - Accounts 
Payable, WIP, and MTC. The tax location information available on the Accounts Payable feed is much more 
limited than 

the information that could be required as part of the manual WIP and MTC processes. As a result, the tax location 
derivation process for all three feeds is based on the information currently available on the Accounts Payable 

inbound file. Basically, there are two pieces of location information available on this feed - the requester's IBM 
employee serial number and the department owning. Given these choices, our panel of tax representatives chose to 

implement a two tiered tax location derivation strategy using the requester's IBM employee serial number as the 
primary source of tax location information 
and the department owning as a secondary source. 

a. TAX LOCATION DERIVATION STRATEGY - OVERVIEW 

The tax location strategy for capitalizations of externally manufactured data processing equipment relies 
exclusively on look ups against the Worldwide RE/SO Building Database. This database integrated with the RE/SO 
Space Tracking Database will allow our system architects to obtain the TAXWARE code and the IBM building 
number for an asset based on the IBM employee serial number of the requester. Using the requester's serial number, 
the system architects will be able to determine the closest office location, including building number and work 
location, of the employee in question. This location information can then be applied to the asset and posted to the 
Asset Master Record. Although it is unlikely that the 

equipment will be located in the requester's office, it is probably located in the same tax jurisdiction. Therefore, our 
panel of tax representatives felt that the requester's location was the best default tax location for externally 
manufactured data processing equipment. Since the majority of this type of equipment will be capitalized 
directly from the Accounts Payable feed, our panel of tax representatives selected a secondary tax location strategy 
to limit the number of errors produced 

by this feed. The secondary tier of this strategy relies on the department owning indicated on the record. Based on 
the department owning, the strategy calls for the system to do a look up against Bluepages to determine the IBM 
employee serial number of the manager of the department in question. Once the manager's IBM employee serial 
number has been 

derived, that serial number should be used to reference the Worldwide RE/SO Database to determine the manager's 
office location. Based on the manager's work location, the Asset Master Record can be updated with the 
corresponding TAXWARE Code and IBM building number. 

b. EXTERNAL DEPENDENCIES 

i. WORLDWIDE RE/SO BUILDING DATABASE 

. The specifics of this database are described in the INTERNALLY MANUFACTURED DATA PROCESSING 
EQUIPMENT - EXTERNAL DEPENDENCIES portion of this document. 

ii. IBM SPACE SUITE - RE/SO SPACE TRACKING DATABASE 

The specifics of this database are described in the INTERNALLY MANUFACTURED DATA PROCESSING 
EQUIPMENT - EXTERNAL DEPENDENCIES portion of this document. 



-9- 



c. SYSTEM REQUIREMENTS 

There are no specific tables and other system requirements necessary for the implementation of this strategy. 
The strategy is simply predicated on the premise that the SAP system will be able to effectively make calls against 
both the Worldwide RE/SO Building Database and Bluepages. 

2.TRANSFERS 

There are two different transfer feeders for externally manufactured data processing equipment - PCF and 
MTT. The tax location information included on both PCF and MTT varies with each transfer. However, in all cases 
where the 

location of the asset changes the-IBM employee serial number of the owner also changes. Given this consistency, 
our panel of tax representatives chose the 'transfer to' IBM employee serial number as the basis for deriving the tax 
location of transferred externally manufactured data processing equipment. 

a. TAX LOCATION DERIVATION STRATEGY - OVERVIEW 

Like capitalizations, the tax location strategy of transfers of externally manufactured data processing 
equipment relies exclusively on calls against the Worldwide RE/SO Building Database. This database integrated 
with the 

RE/SO Space Tracking Database houses the closest office location of every IBM employee in the United States. By 
cross-referencing this informationagainst the 'transfer to' IBM employee serial number provided on the input file, 
the system architects can derive both the TAXWARE Code and the IBM building number. After this information is 
extracted from the Worldwide RE/SO Building Database, the tax location information on the Asset Master Record 
can be overwritten with the updated 'transfer to' location information. 

b. EXTERNAL DEPENDENCIES 

i. WORLDWIDE RE/SO BUILDING DATABASE 

The specifics of this database are described in the INTERNALLY 
MANUFACTURED DATA PROCESSING EQUIPMENT - EXTERNAL DEPENDENCIES portion of this 
document. 

ii. IBM SPACE SUITE - RE/SO SPACE TRACKING DATABASE 

The specifics of this database are described in the INTERNALLY MANUFACTURED DATA PROCESSING 
EQUIPMENT - EXTERNAL DEPENDENCIES portion of this document. 

c. SYSTEM REQUIREMENTS 

There are no specific tables and other system requirements necessary for the implementation of this strategy. 
The strategy is simply predicated on the premise that the SAP system will be able to effectively make calls against 
the Worldwide RE/SO Building Database. 

C. RENTAL DATA PROCESSING EQUIPMENT 

1. CAPITALIZATIONS 

There is only one capitalization source of rental data processing equipment - ICF. The ICF capitalization feed 
contains a limited amount of tax location information. Basically, the only viable location information on this feed is 
restricted to customer number. Considering this obvious limitation, our panel of tax representatives selected 
customer number as the basis for tax 
location derivation for all rental data processing equipment. 

a. TAX LOCATION DERIVATION STRATEGY - OVERVIEW 

The tax location derivation strategy for rental data processing equipment is exactly the same as the tax location 
strategy for internally manufactured data processing equipment. Based on the IBM customer number provided on 
the inbound capitalization record, the state/city/county code can be derived from the SAADB.MINICMR Table. 
This code will then be converted to the associated TAXWARE code by referencing the TAXCALC to TAXWARE 
mapping table (see INTERNALLY MANUFACTURED DATA PROCESSING EQUIPMENT - SYSTEM 
REQUIREMENTS for details on this table). Once this conversion is complete, the Asset Master Record can be 
updated with the tax location information. 
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As with internally manufactured data processing equipment, there is an open issue concerning the required 
derivation of the rental asset's building number. Because the IBM building number information can be maintained 
in any one of four address fields on the SAADB.MINICMR table, it is not possible to derive the building number 
based on a direct call 

against the table. Instead the building number must be derived by referencing the Customer Number Table (see 
INTERNALLY MANUFACTURED DATA PROCESSING EQUIPMENT - SYSTEM REQUIREMENTS for 
details of this 

table). The Customer Number Table includes the IBM customer number and its associated IBM building number. 
However, the present strategy includes a requirement for the SAP Administration Team to do a manual mapping of 
customer numbers to IBM building numbers based on queries against the SAADB.MINICMR table. This manual 
process has been referred 

to the SI Team for alternative approaches that are more automated in nature. 

b. EXTERNAL DEPENDENCIES 

i. MARKET PLACE PROFILE (MPP) 

• The specifics of this database are described in the INTERNALLY MANUFACTURED DATA PROCESSING 
EQUIPMENT - EXTERNAL DEPENDENCIES portion of this document. 

c. SYSTEM REQUIREMENTS 

1. CUSTOMER NUMBER TABLE 

The specifics of this table are described in the INTERNALLY MANUFACTURED DATA PROCESSING 
EQUIPMENT - SYSTEM REQUIREMENTS portion of this document. 

ii. TAXCALC TO TAXWARE MAPPING TABLE 

The specifics of this table are described in the INTERNALLY MANUFACTURED DATA PROCESSING 
EQUIPMENT - SYSTEM REQUIREMENTS portion of this document. 

2. TRANSFERS 

As with capitalizations, there is only source of transfers of rental data processing equipment - AST. The AST 
feed is based on a comparison of changes in the SAADB.STATJFUNC Table from one month to the next. This 
table contains a listing of all internally owned data processing equipment tracked on the AAS system including 
rental equipment. Again, the only viable piece of location information available on the SAADB.STAT_FUNC table 
is the IBM customer number assigned to the asset. As such, our panel of tax representatives selected customer 
number as the basis for the default tax location assignment of all transfers of rental data processing equipment. 

a.TAX LOCATION DERIVATION STRATEGY - OVERVIEW 

The tax location derivation strategy for transfers of rental data processing equipment is exactly the same as the 
tax location strategy for capitalizations of rental data processing equipment. Based on the IBM customer number 
provided on the inbound capitalization record, the state/city/county code can be derived from the 
SAADB.MINICMR Table. This 

code will then be converted to the associated TAXWARE code by referencing the TAXCALC to TAXWARE 
mapping table (see INTERNALLY MANUFACTUREDDATA PROCESSING EQUIPMENT - SYSTEM 
REQUIREMENTS for details on this 

table). Once this conversion is complete, the Asset Master Record can be updated with the tax location information. 
As with internally manufactured data processing equipment, there is an open issue concerning the required 
derivation of the rental asset's building number. Because the IBM building number information can be maintained 
in any one of four address fields on the SAADB.MINICMR table.it is not possible to derive the building number 
based on a direct call 

against the table. Instead the building number must be derived by referencing the Customer Number Table (see 
INTERNALLY MANUFACTURED DATA PROCESSING EQUIPMENT - SYSTEM REQUIREMENTS for 
details of this 

table). The Customer Number Table includes the IBM customer number and its associated IBM building number. 
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However, the present strategy includes a requirement for the SAP Administration Team to do a manual mapping of 
customer numbers to IBM building numbers based on queries against the SAADB.MrNICMR table. This manual 
process has been referred 

to the SI Team for alternative approaches that are more automated in nature. 

b. EXTERNAL DEPENDENCIES 

i. MARKET PLACE PROFILE (MPP) 

The specifics of this database are described in the INTERNALLY MANUFACTURED DATA PROCESSING 
EQUIPMENT - EXTERNAL DEPENDENCIES portion of this document. 

c. SYSTEM REQUIREMENTS 

i. CUSTOMER NUMBER TABLE 

The specifics of this table are described in the INTERNALLY MANUFACTURED DATA PROCESSING 
EQUIPMENT - SYSTEM REQUIREMENTS portion of this document. 

ii. TAXCALC TO TAXWARE MAPPING TABLE 

The specifics of this table are described in the INTERNALLY MANUFACTURED DATA PROCESSING 
EQUIPMENT - SYSTEM REQUIREMENTS portion of this document. 

111. PC EQUIPMENT 

A. INTERNALLY MANUFACTURED PC EQUIPMENT 
1. CAPITALIZATIONS 

There are four capitalization sources of internally manufactured pc equipment - FDS, PCW, WIP, and MTC. 
The tax location information available on the FDS feed is limited to customer number and, in some cases, IBM 
employee 

serial number. The PCW feed, however, contains both customer number and IBM employee serial number as well 
as the ship to zip code and the department using. Finally, the WIP and MTC feeds contain a variety of information 
depending on what is entered by the cap accountant at the point of capitalization. In all cases, though, IBM 
employee serial number is required for capitalizations of internally manufactured pc equipment originating from 
these feeds. Since IBM employee serial is the only piece of tax location information that is common to all four 
capitalization sources of this type of equipment, our panel of tax representatives selected the IBM employee serial 
number as the basis for tax location of internally manufactured pc equipment. 

a. TAX LOCATION DERIVATION STRATEGY - OVERVIEW 

The tax location strategy for capitalizations of internally manufactured pc relies exclusively on look ups against the 
Worldwide RE/SO Building Database. This database integrated with the RE/SO Space Tracking Database will 
allow our system architects to obtain the TAXWARE code and the IBM building number for an asset based on the 
IBM employee serial number on the input record. Using the IBM employee serial number, the system architects 
will be able to determine the closest office location, including building number and work location, of the employee 
in question. This location information can then be applied to the asset and posted to the Asset Master Record. In the 
case of capitalizations of internally manufactured pc equipment originating from the FDS feed, the IBM employee 
serial number is not available on the input file. The only information available on this file is the IBM customer 
number. In order to derive the IBM employee serial number from this information, the customer number should be 
used to reference the AED Table (see SYSTEM REQUIREMENTS for specific information about this table). This 
table provides a mapping of internal customer numbers to 

IBM employee serial numbers. Once the IBM employee serial number is derived based on this mapping, the tax 
location of the equipment can be determined by cross-referencing the IBM employee serial number against the 
Worldwide RE/SO Building Database. This methodology follows the same logic as the tax location derivation for 
all other internally 

manufactured pc equipment as described above. 
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b.EXTERNAL DEPENDENCIES 



i. WORJLDWIDE RE/SO BUILDING DATABASE 

The specifics of this database are described in the INTERNALLY MANUFACTURED DATA PROCESSING 
EQUIPMENT - EXTERNAL DEPENDENCIES portion of this document. 

ii. OIBM SPACE SUITE - RE/SO SPACE TRACKING DATABASE 

The specifics of this database are described in the INTERNALLY MANUFACTURED DATA PROCESSING 
EQUIPMENT - EXTERNAL DEPENDENCIES portion of this document. 

c. • SYSTEM REQUIREMENTS 

i. AED TABLE 

The AED Table is required in order to derive the tax location of internally manufactured pc equipment that is 
capitalized via the FDS feed.This table maps the internal customer number from the input file to the IBM employee 
serial number of the employee who requested the customer number. 
1 EXAMPLE TABLE: 

[Country [Customer Number [Employee Serial Number 
il 5 |0 '1 145 143700 ' 

[US [002334 " [573391 

__ |-- 0 ' 0 ^ [024727 [ 



FIELD DERIVATION MATRIX: 



|FieldName [Derivation 


|Country |Hardcoded to 'US' 


Customer Number 


Manually Input by IGS Contact Based on Approved AEFORMS from the Bethesda Branch 
Office 


Employee Serial 
Number 


Manually Input by IGS Contact Based on Approved AEFORMS from the Bethesda Branch 
Office, Value Equals the Requester of the AEFORMS 



OPEN ISSUE: 

At the time these requirements were finalized, the decision as to whether AED Table or the PACT Table would 
be used to capitalize IGS assets had not been made. Regardless of which table is selected, a mapping of internal 
customer numbers to IBM employee serial numbers needs to be provided to support the tax location strategy for 
internally manufactured pc equipment. 

2. TRANSFERS 

There are two different transfer feeders for internally manufactured pc equipment - PCF and MTT. The tax 
location information included on both PCF and MTT varies with each transfer. However, in all cases where the 
location of the asset 

changes the IBM employee serial number of the owner also changes. Given this consistency, our panel of tax 
representatives chose the 'transfer to' IBM employee serial number as the basis for deriving the taxlocation of 
transferred externally manufactured data processing equipment. 
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a. TAX LOCATION DERIVATION STRATEGY - OVERVIEW 

Like capitalizations, the tax location strategy of transfers of internally manufactured pc equipment relies 
exclusively on calls against the Worldwide RE/SO Building Database. This database integrated with the RE/SO 
Space Tracking Database houses the closest office location of every IBM employee in the United States. By cross- 
referencing this information against the 'transfer to' IBM employee serial number provided on the input file, the 
system architects can derive both the TAXWARE Code and the IBM building number. After this information is 
extracted from the Worldwide 

RE/SO Building Database, the tax location information on the Asset Master Record can be overwritten with the 
updated 'transfer to' location information. 

b. EXTERNAL DEPENDENCIES 

i. WORLDWIDE RE/SO BUILDING DATABASE 

The specifics of this database are described in the INTERNALLY MANUFACTURED DATA PROCESSING 
EQUIPMENT - EXTERNAL DEPENDENCIES portion of this document. 

ii. IBM SPACE SUITE - RE/SO SPACE TRACKING DATABASE 

The specifics of this database are described in the INTERNALLY MANUFACTURED DATA PROCESSING 
EQUIPMENT - EXTERNAL DEPENDENCIES portion of this document. 

c. SYSTEM REQUIREMENTS 

. There are no specific tables and other system requirements necessary for the implementation of this strategy. 
The strategy is simply predicated on the premise that the SAP system will be able to effectively make calls against 
the Worldwide RE/SO Building Database. 

B. EXTERNALLY MANUFACTURED PC EQUIPMENT 

1. CAPITALIZATIONS 

There are three capitalization sources of externally manufactured pc equipment - Accounts Payable, WIP, and 
MTC. The tax location information available on the Accounts Payable feed is much more limited than the 
information that could be required as part of the manual WIP and MTC processes. As a result, the tax location 
derivation process for all three feeds 

is based on the information currently available on the Accounts Payable inbound file. Basically, there are two 
pieces of location information available on this feed - the requester's IBM employee serial number and the 
department 

owning. Given these choices, our panel of tax representatives chose to implement a two tiered tax location 
derivation strategy using the requester's IBM employee serial number as the primary source of tax location 
information 

and the department owning as a secondary source. 

a. TAX LOCATION DERIVATION STRATEGY - OVERVIEW 

The tax location strategy for capitalizations of externally manufactured pc equipment relies exclusively on look 
ups against the Worldwide RE/SO Building Database. This database integrated with the RE/SO Space Tracking 
Database will allow our system architects to obtain the TAXWARE code and the IBM building number for an asset 
based on the IBM employee serial number of the requester. Using the requester's serial number, the system 
architects will be able to determine the closest office location, including building number and work location, of the 
employee in question. This 

location information can then be applied to the asset and posted to the Asset Master Record. Since the majority of 
externally manufactured pc equipment will be capitalized directly from the Accounts Payable feed, our panel of tax 
representatives selected a secondary tax location strategy to limit the number of errors produced by this feed. The 
secondary tier of this strategy relies on the department owning indicated on the record. Based on the 
department owning, the strategy calls for the system to do a look up against Bluepages to determine the IBM 
employee serial number of the manager of the department in question. Once the manager's IBM employee serial 
number has been derived, that serial number should be used to reference the Worldwide RE/SO Database to 
determine the manager's office location. Based on the manager's work location, the Asset Master Record can be 
updated with the corresponding TAXWARE Code and IBM building number. 
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b. EXTERNAL DEPENDENCIES 



1. WORLDWIDE RE/SO BUILDING DATABASE 

The specifics of this database are described in the INTERNALLY MANUFACTURED DATA PROCESSING 
EQUIPMENT - EXTERNAL DEPENDENCIES portion of this document. 

ii. IBM SPACE SUITE - RE/SO SPACE TRACKING DATABASE 

The specifics of this database are described in the INTERNALLY MANUFACTURED DATA PROCESSING 
EQUIPMENT - EXTERNAL DEPENDENCIES portion of this document. 

c. SYSTEM REQUIREMENTS 

There are no specific tables and other system requirements necessary for the implementation of this strategy. 
The strategy is simply predicated on the premise that the SAP system will be able to effectively make calls against 
both the Worldwide RE/SO Building Database and Bluepages. 

2. TRANSFERS 

There are two different transfer feeders for externally manufactured pc equipment - PCF and MTT. The tax 
location information included on both PCF and MTT varies with each transfer. However, in all cases where the 
location of the asset 

changes the IBM employee serial number of the owner also changes. Given this consistency, our panel of tax 
representatives chose the 'transfer to' IBM employee serial number as the basis for deriving the tax location of 
transferred externally manufactured pc equipment. 

a. TAX LOCATION DERIVATION STRATEGY - OVERVIEW 

Like capitalizations, the tax location strategy of transfers of externally manufactured pc equipment relies 
exclusively on calls against the Worldwide RE/SO Building Database. This database integrated with the RE/SO 
Space Tracking Database houses the closest office location of. every IBM employee in the United States. By cross- 
referencing this information against the 'transfer to' IBM employee serial number provided on the input file, the 
system architects can derive both the TAXWARE Code and the IBM building number. After this information is 
extracted from the Worldwide 

RE/SO Building Database, the tax location information on the Asset Master Record can be overwritten with the 
updated 'transfer to' location information. 

b. EXTERNAL DEPENDENCIES 

i. WORLDWIDE RE/SO BUILDING DATABASE 

The specifics of this database are described in the INTERNALLY MANUFACTURED DATA PROCESSING 
EQUIPMENT - EXTERNAL DEPENDENCE Sportion of this document. 

ii. IBM SPACE SUITE - RE/SO SPACE TRACKING DATABASE 

The specifics of this database are described in the INTERNALLY MANUFACTURED DATA PROCESSING 
EQUIPMENT - EXTERNAL DEPENDENCIES portion of this document. 

c. SYSTEM REQUIREMENTS 

,. There are no specific tables and other system requirements necessary for the implementation of this strategy. 
The strategy is simply predicated on the premise that the SAP system will be able to effectively make calls against 
the Worldwide RE/SO Building Database. 

C. LOANER, DEMONSTRATION, AND TRIAL EQUIPMENT 

1. CAPITALIZATIONS 

There are only two capitalization sources of loaner, demonstration and trial equipment - WIP and MTC. 
Although, both the WIP and MTC feeds can be customized to include a myriad of tax location information, the only 
significant piece of data is the loaner number on the record. Since loaner, demonstration, and trial equipment is 
often housed in a different tax jurisdiction than that of the asset owner, the asset owner's IBM employee serial 
number is not an appropriate basis for tax location derivation. As such, another tax location derivation strategy had 



to be developed. The approach agreed upon by our panel of tax representatives is based on the creation of a series of 
ten digit numbers called loaner numbers. These loaner numbers represent the customers' addresses where the 
equipment is located. It is the 

responsibility of the loaner pool administrators to maintain the listing of loaner numbers and their corresponding 
addresses. When a piece of loaner, demonstration or trial equipment is capitalized, the. WIP accountant must obtain 
the associated loaner number from the loaner pool administrator in order to complete the capitalization via the CO 
module or via an MTC file. 

a. TAX LOCATION DERIVATION STRATEGY - OVERVIEW 

The tax location strategy for capitalizations of loaner, demonstration or trial equipment relies exclusively on 
look ups against the Loaner Number Table (see SYSTEM REQUIREMENTS for specific information about this 
table). 

Based on the loaner number, the system architects can retrieve the TAXWARE code associated with the asset's 
location and post it to the Asset Master Record. 

b. EXTERNAL DEPENDENCIES 

There are no specific external dependencies required for the implementation of this tax location strategy. The 
strategy relies completely upon the cooperation of the loaner pool administrators and their willingness to 
maintain a loaner number listing. 

c. SYSTEM REQUIREMENTS 

i. LOANER NUMBER TABLE 

The Loaner Number Table is required in order to derive the tax location of loaner, demonstration and trial 
equipment that is capitalized via the WIP and MTC feeds. This table maps the loaner number from the input file 
to the 

TAXWARE code associated with the asset's physical address. 



Country: 


Loaner 
Number 


Company Name 


Street Address 


Postal I 
Code j 


TAXWARE 
Code 


US 


001045 


XACT, Inc. 


1445 Macarthur Drive; Suite 
244 


75007 


421130480 


|US J002334 ;|ADT Security Systems i|430 Oak Grove Street; Suite 204 ;|55403 |220530650 


US | 


000456 


Ability Building 
Center 


1911 14th Street NW 


55903 i 


221090900 



FIELD DERIVATION MATRIX: 



[Field Name 


;|Derivation 


Countr) 


[Hardcoded to 'US' 


|Loaner Number 


|Manually Input by SAP Administrator - Sequential Numbering Scheme 


|Company Name 


|Manually Input by SAP Administrator Based on Lotus Note from Loaner Pool Administrator 


|Street Address 


[Manually Input by SAP Administrator Based on Lotus Note from Loaner Pool Administrator 


|Postal Code 


jManually Input by SAP Administrator Based on Lotus Note from Loaner Pool Administrator 
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TAXWARE 
Code 



Manually Input by SAP Administrator - Coordination with PPT Required to Assign TAXWARE 
Code 



OPEN ISSUE: 

The SAP Administration Team has expressed a concern regarding the amount of manual work this table will 
require in order to maintain. All possible avenues for automation should be explored. Since the loaner number 
updates are going to be sent en mass to SAP, one suggestion might be to have the loaner administrator include the 
address information on this mass update file. In theory, the system could extract the address 
information associated with the loaner number and load it to the table automatically. If this method was employed, 
the SAP Administration Team would only be responsible for entering the TAXWARE code information into 
the Loaner Table. 

2. TRANSFERS 

There are two different transfer feeders for loaner, demonstration and trial equipment - PCF and MTT. The tax 
location information included on both PCF and MTT varies with each transfer. However, in the case of loaner, 
demonstration and trial equipment one piece of information is required on all transfers - the loaner number. These 
transfers are initiated by the loaner pool administrators either by submitting monthly update files or initiating 
transfers via PCF. 

a. TAX LOCATION DERIVATION STRATEGY - OVERVIEW 

Like capitalizations, the tax location strategy of transfers of loaner, demonstration and trial equipment relies 
exclusively on calls against the Loaner Number Table. Based on the 'transfer to' loaner number on the input file, 
the system architects can perform a lookup against the Loaner Table and derive the associated TAXWARE Code. 

b. EXTERNAL DEPENDENCIES 

There are no specific external dependencies required for the implementation of this tax location strategy. The 
strategy relies completely upon the cooperation of the loaner pool administrators and their willingness to maintain a 
loaner number listing and submit the required updates. 

c. SYSTEM REQUIREMENTS 

i. LOANER NUMBER TABLE 

The Loaner Number Table is required in order to derive the tax location of loaner, demonstration and trial 
equipment that is transferred via the PCF and MTT feeds. This table maps the loaner number from the input file to 
the 

TAXWARE code associated with the asset's physical address. 
IV. MACHINERY AND EQUIPMENT 

A. INTERNALLY MANUFACTURED MACHINERY AND EQUIPMENT 
1. CAPITALIZATIONS 

., There are two capitalization sources of internally manufactured machinery and equipment - WIP and MTC. 
There is a variety of location information available on both of these feeds depending upon what the WIP accountant 
chooses to 

enter at the point of capitalization. However, there is one piece of location information that is required on all 
capitalizations of internally manufactured machinery and equipment - the asset owner's employee serial. Because 
this 

information is consistently required, our panel of tax representatives selected the IBM employee serial number as the 
basis for tax location assignment for this type of equipment. 

a. TAX LOCATION DERIVATION STRATEGY - OVERVIEW 

The tax location strategy for capitalizations of internally manufactured machinery and equipment relies 
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exclusively on look ups against the Worldwide RE/SO Building Database. This database integrated with the RE/SO 
Space Tracking Database will allow our system architects to obtain the TAXWARE code and the IBM building 
number for an asset based on the IBM employee serial number of the asset owner. Using the asset owner's serial 
number, the system architects will be able to determine the closest office location, including building number and 
work location, of the employee in question. This location information can then be applied to the asset and posted to 
the Asset Master Record. 

b. EXTERNAL DEPENDENCIES 

1. WORLDWIDE RE/SO BUILDING DATABASE 

The specifics of this database are described in the INTERNALLY MANUFACTURED DATA PROCESSING 
EQUIPMENT - EXTERNAL DEPENDENCIES portion of this document. 

ii. IBM SPACE SUITE - RE/SO SPACE TRACKING DATABASE 

The specifics of this database are described in the INTERNALLY MANUFACTURED DATA PROCESSING 
EQUIPMENT - EXTERNAL DEPENDENCIES portion of this document. 

c. SYSTEM REQUIREMENTS 

There are no specific tables and other system requirements necessary for the implementation of this strategy. 
The strategy is simply predicated on the premise that the SAP system will be able to effectively make calls against 
both the Worldwide RE/SO Building Database and Bluepages. 

2. TRANSFERS 

There are two different transfer feeders for externally manufactured pc equipment - PCF and MTT. The tax 
location information included on both PCF and MTT varies with each transfer. However, in all cases where the 
location of the asset 

changes the IBM employee serial number of the owner also changes. Given this consistency, our panel of tax 
representatives chose the 'transfer to' IBM employee serial number as the basis for deriving the tax location of 
transferred internally manufactured machinery and equipment. 

a. TAX LOCATION DERIVATION STRATEGY - OVERVIEW 

Like capitalizations, the tax location strategy of transfers of internally manufactured machinery and 
equipment relies exclusively on calls against the Worldwide RE/SO Building Database. This database integrated 
with the RE/SO Space Tracking Database houses the closest office location of every IBM employee in the United 
States. By cross-referencing this information against the 'transfer to' IBM employee serial number provided on the 
input file, the system architects can derive both the TAXWARE Code and the IBM building number. After this 
information is extracted from the Worldwide RE/SO Building Database, the tax location information on the Asset 
Master Record can be overwritten with the updated 'transfer to' location information. 

b. EXTERNAL DEPENDENCIES 

i. WORLDWIDE RE/SO BUILDING DATABASE 

The specifics of this database are described in the INTERNALLY MANUFACTURED DATA PROCESSING 
EQUIPMENT - EXTERNAL DEPENDENCIES portion of this document. 

ii. IBM SPACE SUITE - RE/SO SPACE TRACKING DATABASE 

' The specifics of this database are described in the INTERNALLY MANUFACTURED DATA PROCESSING 
EQUIPMENT - EXTERNAL DEPENDENCIES portion of this document. 

c. SYSTEM REQUIREMENTS 

There are no specific tables and other system requirements necessary for the implementation of this strategy. 
The strategy is simply predicated on the premise that the SAP system will be able to effectively make calls against 
the Worldwide RE/SO Building Database. 

B. VENDOR RETAINED TOOLING 
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1. CAPITALIZATIONS 

There are only two capitalization sources of vendor retained tooling - WIP and MTC. Although, both the WIP 
and MTC feeds can be customized to include a myriad of tax location information, the only significant piece of data 
is the vendor number on the record. Since vendor retained tooling is often housed in a different tax jurisdiction than 
that of the asset owner, the asset owner's IBM employee serial number is not an appropriate basis for tax location 
derivation. As such, another tax location derivation strategy had to be developed. The approach agreed upon by our 
panel of tax representatives is based on the vendor number assigned by accounts payable. This vendor number 
represents the company name and physical address of the vendor who has possession of the equipment. When a 
piece of vendor retained tooling is capitalized, the WIP accountant must input the associated vendor number in order 
to complete the capitalization via the CO module or via an MTC file. 

a. TAX LOCATION DERIVATION STRATEGY - OVERVIEW 

The tax location strategy for capitalizations of vendor retained tooling relies exclusively on look ups against the 
Vendor Number Table (see SYSTEM REQUIREMENTS for specific information about this table). Based on the 
vendor number, the system architects can retrieve the TAXWARE code associated with the asset's location and post 
it to the Asset Master Record. 

b. EXTERNAL DEPENDENCIES 

There are no specific external dependencies required for the implementation of this tax location strategy. The 
strategy relies completely upon the manual entry of the vendor numbers by the WIP accountant at the point of 
capitalization. 

c. SYSTEM REQUIREMENTS 

i. VENDOR NUMBER TABLE 

The Vendor Number Table is required in order to derive the tax location of vendor retained tooling is 
capitalized via the WIP and MTC feeds. This table maps the vendor number from the input file to the TAXWARE 
code associated 

with the asset's physical address. 



EXAMPLE TABLE: 



[Country: j Vendor Table | Vendor Name 


Street Address Postal Code [t AX WARE Code 


US ; 10001023 ;|OnanCorp. 


9713 Valley View Road 55344 


[220530650 \ 


]US |0001534 Jonathan Mfg Corp. 


1 101 South Acacia Ave. |92631 


040591310 : 


|US |0001 132 ;|Amray, Inc. 


160 Middlesex Tpke 01730 


200170075 



FIELD DERIVATION MATRIX: 



|Country |Hardcoded to 'US' 

v ii 1 N i«t i l 'ai ml! Jrr i SAI In n rtrator b> Referencing Accounts Payable Vendor Table 

[Vendor Name Mai u ill) Input by SAP Administrator by Referencing Accounts Payable Vendor Table 

[street Address [Manually Input by SAP Administrator by Referencing Accounts Payable Vendor Table 

[Postal Code |Manually Input by SAP Adminisfrator by Referencing Accounts Payable Vendor Table 

| TAXWARE ' Manually Input by SAP Administrator - Coordination with PPT Required to Assign TAXWARE 

Code Code 



OPEN ISSUE: 

The SAP Administration Team has expressed a concern regarding the amount of manual work this table will require 
in order to maintain. If possible this manual table load process should be replaced by a direct feed from Accounts 
Payable. 

2. TRANSFERS 

There are two different transfer feeders for vendor retained tooling - PCF and MTT. The tax location 
information included on both PCF and MTT varies with each transfer. However, in the case of vendor retained 
tooling one piece of information is required on all transfers - the vendor number. These transfers are initiated by the 
asset owners either by submitting an update file or initiating transfers via PCF. 

a. TAX LOCATION DERIVATION STRATEGY - OVERVIEW 

Like capitalizations, the tax location strategy of transfers of vendor retained tooling relies exclusively on calls 
against the Vendor Number Table. Based on the 'transfer to' vendor number on the input file, the system architects 
can perform a lookup against the Vendor Table and derive the associated TAXWARE Code. 

b. EXTERNAL DEPENDENCIES 

There are no specific external dependencies required for the implementation of this tax location strategy. The 
strategy relies completely upon the input of the asset owner. 

c. SYSTEM REQUIREMENTS 

i. " VENDOR NUMBER TABLE 

The Vendor Number Table is required in order to derive the tax location of vendor retained tooling that is 
transferred via the PCF and MTT feeds. This table maps the vendor number from the input file to the 
TAXWARE code 

associated with the asset's physical address. 

V. FURNITURE AND FIXTURES 

A. INVENTOR! ABLE FURNITURE AND FIXTURES 

1.' CAPITALIZATIONS 

There are two capitalization sources of inventoriable furniture and fixtures -WIP and MTC. There is a variety 
of location information available on both of these feeds depending upon what the WIP accountant chooses to enter 
at the 

point of capitalization. However, there is one piece of location information that is required on all capitalizations of 
inventoriable furniture and fixtures - the asset owner's employee serial number. Because this information is 
consistently required, our panel of tax representatives selected the IBM employee serial number as the basis for tax 
location assignment for this type of equipment. 

a. TAX LOCATION DERIVATION STRATEGY - OVERVIEW 

The tax location strategy for capitalizations of inventoriable furniture and fixtures relies exclusively on look 
ups against the Worldwide RE/SO Building Database. This database integrated with the RE/SO Space Tracking 
Database 

will allow our system architects to obtain the TAXWARE code and the IBM building number for an asset based on 
the IBM employee serial number of the asset owner. Using the asset owner's serial number, the system 
architects will be able to determine the closest office location, including building number and work location, of the 
employee in question. This location information can then be applied to the asset and posted to the Asset Master 
Record. b. EXTERNAL DEPENDENCIES 
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1. WORLDWIDE RE/SO BUILDING DATABASE 

The specifics of this database are described in the INTERNALLY MANUFACTURED DATA PROCESSING 
EQUIPMENT - EXTERNAL DEPENDENCIES portion of this document. 

ii. IBM SPACE SUITE - RE/SO SPACE TRACKING DATABASE 

The specifics of this database are described in the INTERNALLY MANUFACTURED DATA PROCESSING 
EQUIPMENT - EXTERNAL DEPENDENCIES portion of this document. 

c. .. SYSTEM REQUIREMENTS 

There are no specific tables and other system requirements necessary for the implementation of this strategy. 
The strategy is simply predicated on the premise that the SAP system will be able to effectively make calls against 
both the Worldwide RE/SO Building Database and Bluepages. 

2. TRANSFERS 

There are two different transfer feeders for inventoriable furniture and fixtures - PCF and MTT. The tax 
location information included on both PCF and MTT varies with each transfer. However, in all cases where the 
location of the asset 

changes the IBM employee serial number of the owner also changes. Given this consistency, our panel of tax 
representatives chose the 'transfer to' IBM employee serial number as the basis for deriving the tax location of 
transferred inventoriable furniture and fixtures. 

a. TAX LOCATION DERIVATION STRATEGY - OVERVIEW 

Like capitalizations, the tax location strategy of transfers of inventoriable furniture and fixtures relies 
exclusively on calls against the Worldwide RE/SO Building Database. This database integrated with the RE/SO 
Space Tracking 

Database houses the closest office location of every IBM employee in the United States. By cross-referencing 
this information against the 'transfer to' IBM employee serial number provided on the input file, the system 
architects 

can derive both the TAXWARE Code and the IBM building number. After this information is extracted from the 
Worldwide RE/SO Building Database, the tax location information on the Asset Master Record can be overwritten 
with the updated 'transfer to' location information. 

b. EXTERNAL DEPENDENCIES 

i. WORLDWIDE RE/SO BUILDING DATABASE 

The specifics of this database are described in the INTERNALLY MANUFACTURED DATA PROCESSING 
EQUIPMENT - EXTERNAL DEPENDENCIES portion of this document. 

ii. IBM SPACE SUITE - RE/SO SPACE TRACKING DATABASE 

The specifics of this database are described in the INTERNALLY MANUFACTURED DATA PROCESSING 
EQUIPMENT - EXTERNAL DEPENDENCIES portion of this document. 

c. SYSTEM REQUIREMENTS 

There are no specific tables and other system requirements necessary for the implementation of this strategy. 
The strategy is simply predicated on the premise that the SAP system will be able to effectively make calls against 
the Worldwide RE/SO Building Database. 

B. NON-INVENTORIABLE FURNITURE AND FIXTURES 

1. CAPITALIZATIONS 

There are three capitalization sources of non-inventoriable furniture and fixtures - Accounts Payable, WIP and 
MTC. The tax location information available on the Accounts Payable feed is much more limited than the 
information that could be required as part of the manual WIP and MTC processes. As a result, the tax location 
derivation process for all three feeds 

is based on the information currently available on the Accounts Payable inbound file. Given this restriction, it was 
originally proposed that the postal zip code on the accounts payable record be used to make a call against a new 
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Postal Zip Code to AUO Mapping Table. However, this strategy was based on the assumption that the postal zip 
code represented the 'ship to' postal zip code. Further investigation has determined that the zip code on the 
accounts payable record actually represents the vendor's postal zip code. As such, a strategy that relies on the zip 
code on the accounts payable record is not a 

viable tax location strategy. An alternate strategy using the same type of logic has been proposed. This strategy 
relies on the requester' s IBM employee serial number to determine the location of the requester and use that 
location to identify the default AUO department the equipment should be capitalized to. 

a. TAX LOCATION DERIVATION STRATEGY - OVERVIEW 

■ The tax location strategy for capitalizations of non-inventoriable furniture and fixtures varies depending on the 
capitalization source. For non- inventoriable furniture and fixtures capitalized via the accounts payable 
feed, the strategy is multi-tiered. First, the requester's IBM employee serial number is used to make a call against 
the Worldwide RE/SO Building Database. This database integrated with the RE/SO Space Tracking Database will 
allow our system architects to obtain the postal zip code of the requester's office location. That postal zip code 
could then be used 

to make a call against the Zip Code to AUO Mapping Table (specific requirements for this table are described under 
the SYSTEM REQUIREMENTS portion of this topic). Based on the postal zip code of the requester's 
location, the AUO department, the IBM building number and the TAXWARE code can be derived from this table. 
This location information can then be applied to the asset and posted to the Asset Master Record. 

For capitalizations of non-inventoriable furniture and fixtures from the WIP or MTC feeds, the strategy is much 
simpler. Since these feeds are driven by manual input, the WIP accountant will be required to check the invoice for 
the ship to zip code. Based on that postal zip code, the WIP accountant will select the corresponding AUO 
department off of the Postal Zip Code to AUO Mapping Table. This AUO department will be entered as part of the 
capitalization record. The system architects will then use the AUO department on the input record to make a call 
against the Postal Zip Code to 

AUO Mapping Table. Based on the AUO department from the input record, the IBM building number and the 
TAXWARE code can be derived. This location information can then be applied to the asset and posted to the Asset 
Master Record. 

b. EXTERNAL DEPENDENCIES 

i. WORLDWIDE RE/SO BUILDING DATABASE 

The specifics of this database are described in the INTERNALLY MANUFACTURED DATA PROCESSING 
EQUIPMENT - EXTERNAL DEPENDENCIES portion of this document. 

ii. IBM SPACE SUITE - RE/SO SPACE TRACKING DATABASE 1 

The specifics of this database are described in the INTERNALLY MANUFACTURED DATA PROCESSING 
EQUIPMENT - EXTERNAL DEPENDENCIES portion of this document. 

c. SYSTEM REQUIREMENTS 

i. POSTAL ZIP CODE TO AUO MAPPING TABLE 

This table is required in order to derive the AUO department necessary to build the lotcap inventory number on 
capitalizations of non-inventoriable equipment from the accounts payable feed. In addition to the lotcap inventory 
number creation, the table is also required to derive the IBM building number and TAXWARE code for all 
capitalizations 

of non-inventoriable furniture and fixtures. 
EXAMPLE TABLE: 

|Country |Postal Zip Code jLocal Division [Cost Center (Building Number |TAXWARE Code* 
[US [80301 [SG : |ZNT ~~~|SGPLD0501 |050130040 ~ 

[US |30327 [fcT |AHB |FCPLB861 j 101210080 ' 

|US :|27709 [l0 ~ [AG5 |lORPL676 |040371900 1 
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[UST |27713 ^[To~ 



|ASO |10RPL500 |040371901 



FIELD DERIVATION MATRIX: 



|Field Name ; 


Derivation 


[Country 


Hardcoded to 'US' 


(Postal Zip Code 


Manually Input by SAP dministration 1 ni ised on SAP apitalization Errors 


[Local Division j 


Deri A roi i , > r . T bl Ba ed >n the < ■ ( ntei 


jCost Center j 


Manually Input by SAP Administration Team - Coordination with WIP Accountants Required to i 
Set Up AUOs 


|BuiIding Number |Manually Input by SAP Administration Team Based on Contact with the PPT Department 


TAXWARE 
Code 


Derived from the Building Table based on the Building Number 



1 OPEN ISSUE: 

The initial set up of this table will require coordination with the WIP accounting community to set up the AUO 
departments and the PPT department to identify the associated building numbers. In addition, research will need to 
be performed to determine which postal zip codes should be loaded to the table. This research should be based on 
the 

postal zip codes for each work location listed in the Worldwide RE/SO Building Database. 
VI. BUILDINGS AND BUILDING EQUIPMENT 
A. BUILDINGS AND BUILDING EQUIPMENT 
1. CAPITALIZATIONS 

There are only two capitalization sources of buildings and building equipment - WIP and MTC. Although, 
both the WIP and MTC feeds can be customized to include a myriad of tax location information, the only significant 
piece of data 

is the building number on the record. This building number represents the IBM building number and work location 
where the building assets are located. When buildings or building equipment are capitalized, the WIP accountant 
must input the associated building number in order to complete the capitalization via the CO module or via an MTC 
file. 

a. TAX LOCATION DERIVATION STRATEGY - OVERVIEW 

The tax location strategy for capitalizations of buildings and building equipment relies exclusively on 
look ups against the Building Number Table (see SYSTEM REQUIREMENTS for specific information about this 
table). Based 
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on the building number, the system architects can retrieve the TAX WARE code associated with the asset's location 
and post it to the Asset Master Record. 

b. EXTERNAL DEPENDENCIES 

There are no specific external dependencies required for the implementation of this tax location strategy. The 
strategy relies completely upon the manual entry of the building numbers by the WIP 
accountant at the point of capitalization. 

c. SYSTEM REQUIREMENTS 

i. BUILDING NUMBER TABLE 

The Building Number Table is required in order to derive the tax location of buildings and building equipment 
that are capitalized via the WIP and MTC feeds. This table maps the building number from the input file to the 
TAXWARE code associated with the asset's physical address. 

EXAMPLE TABLE: 



[Countr Building Number j\Vork Location |R£ SO Building Number : Street Address TAXWARE Code 



US 


JPLD0501 


|PLD 


0501 


|5600 Cottle Road J050130040 


us 


PLB861 


J PLB 


|861 


: |1000 River Street Jl01210080 


us 


i|RPL676 


Jrpl 


:|676 


14407 Silicon Drive 040371900 



FIELD DERIVATION MATRIX: 



[Field Name 


[Derivation 




[Country 


Hardcoded to 'US' 




[Building Number 


Work Location + RE/SO Building Number 




[Work Location 


Derived from the RE/SO Worldwide Building Date 


base; Field Name = Work Location 


RE/SO Building 
Number 


Derived from the RE/SO Worldwide Building Database; Field Name = Building Id 

I • ,. . • 


[Street Address 


Derived from the RE/SO Worldwide Building Date 


base; Field Name = Address 


TAXWARE Code 


Derived from the RE/SO Worldwide Building Date 
Assigned 


base; Field Name Has Not Been 



OPEN ISSUE: 

The PPT Department has requested that the contents of this table be validated against the Worldwide RE/SO 
Building Database on a monthly basis. This validation job should be written to produce a report of 
discontinued facilities. This report will need to manually worked by the SAP Administration Team insuring that all 
active assets are assigned to active facilities. 

2. TRANSFERS 

There is only one transfer feeder for buildings and building equipment - MTT. The tax location information 
included on the MTT feed varies with each transfer. However, in all cases where the location of the asset changes 
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the building number of the asset also changes. Given this consistency, our panel of tax representatives 

chose the 'transfer to' building number as the basis for deriving the tax location of transferred buildings and building 

equipment. 

a. TAX LOCATION DERIVATION STRATEGY - OVERVIEW 

Like capitalizations, the tax location strategy of transfers of buildings and building equipment relies exclusively 
on calls against the Building Table. This table maps building numbers to their associated TAXWARE code. Once 
this call 

is made based on the 'transfer to' building number, the resulting tax location information can be posted to the Asset 
Master Record. 

b. EXTERNAL DEPENDENCIES 

There are no specific external dependencies required for the implementation of this tax location strategy. The 
strategy relies completely upon the manual entry of the building numbers by the transfer accountant at the point of 
transfer. 

c. . SYSTEM REQUIREMENTS 

i. BUILDING NUMBER TABLE 

The Building Number Table is required in order to derive the tax location of buildings and building equipment 
that are capitalized via the WIP and MTC feeds. This table maps the building number from the input file to the 
TAXWARE code associated with the asset's physical address. 

VII. NON-FINANCIAL ASSETS 

A. NON-FINANCIAL ASSETS 

1. ' CAPITALIZATIONS 

There is only one capitalization source for non-financial assets - MTC. There is a variety of location 
information available on the MTC depending upon what the WIP accountant chooses to enter at the point of 
capitalization. However, there is one piece of location information that is required on all capitalizations of non- 
financial assets - the asset owner's employee serial number. Because this information is consistently required, 
our panel of tax representatives selected 

the IBM employee serial number as the basis for tax location assignment for this type of equipment. 

a. TAX LOCATION DERIVATION STRATEGY - OVERVIEW 

■ The tax location strategy for capitalizations of non-financial assets relies exclusively on look ups against the 
Worldwide RE/SO Building Database. This database integrated with the RE/SO Space Tracking Database will 
allow our 

system architects to obtain the TAXWARE code and the IBM building number for an asset based on the IBM 
employee serial number of the asset owner Using the asset owner's serial number, the system architects will be able 
to 

determine the closest office location, including building number and work location, of the employee in question. 
This location information can then be applied to the asset and posted to the Asset Master Record. 

b. . EXTERNAL DEPENDENCIES 

i. WORLDWIDE RE/SO BUILDING DATABASE 

The specifics of this database are described in the INTERNALLY MANUFACTURED DATA PROCESSING 
EQUIPMENT - EXTERNAL DEPENDENCIES portion of this document. 

ii. IBM SPACE SUITE - RE/SO SPACE TRACKING DATABASE 

The specifics of this database are described in the INTERNALLY MANUFACTURED DATA PROCESSING 
EQUIPMENT - EXTERNAL DEPENDENCIES portion of this document. 

c. SYSTEM REQUIREMENTS 

There are no specific tables and other system requirements necessary for the implementation of this strategy. 
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The strategy is simply predicated on the premise that the SAP system will be able to effectively make calls against 
both the Worldwide RE/SO Building Database and Bluepages. 

2. TRANSFERS 

There are two different transfer feeders for non-financial assets - PCF and MTT. The tax location information 
included on both PCF and MTT varies with each transfer. However, in all cases where the location of the asset 
changes the IBM employee serial number of the owner also changes. Given this consistency, our panel of tax 
representatives chose the 'transfer to' IBM employee serial number as the basis for deriving the tax location of 
transferred non-financial assets. 

a. TAX LOCATION DERIVATION STRATEGY - OVERVIEW 

Like capitalizations, the tax location strategy of transfers of non-financial assets relies exclusively on calls 
against the Worldwide RE/SO Building Database. This database integrated with the RE/SO Space Tracking 
Database 

houses the closest office location of every IBM employee in the United States. By cross-referencing this information 
against the 'transfer to' IBM employee serial number provided on the input file, the system architects can derive 
both the TAXWARE Code and the IBM building number. After this information is extracted from the Worldwide 
RE/SO Building Database, the tax location information on the Asset Master Record can be overwritten with the 
updated 'transfer to' location information. 

b. EXTERNAL DEPENDENCIES 

i. WORLDWIDE RE/SO BUILDING DATABASE 

The specifics of this database are described in the INTERNALLY MANUFACTURED DATA PROCESSING 
EQUIPMENT - EXTERNAL DEPENDENCIES portion of this document. 

ii. IBM SPACE SUITE - RE/SO SPACE TRACKING DATABASE 

The specifics of this database are described in the INTERNALLY MANUFACTURED DATA PROCESSING 
EQUIPMENT - EXTERNAL DEPENDENCIES portion of this document. 

c. SYSTEM REQUIREMENTS 

There are no specific tables and other system requirements necessary for the implementation of this strategy. 
The strategy is simply predicated on the premise that the SAP system will be able to effectively make calls against 
the Worldwide RE/SO Building Database. 
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EXHIBIT B 



Tax Location Derivation (ABF) 



Created By: Dilip Pad 

l.-n.st Changed By: Hilip Paid 

Culegotj : PFS 

Sub Category: Tax Location Assignment 

System Component Additional Bridge Functions 



1 . Location Type field is required for Web Front-end (PCF) 

2. Validity and population of TXJCD on our RESO table will be part of table load process, therefor 

blank is valid value. 

3 . Work Loc. + Bldg. will be on MPP 

Main objective of Tax Location Derivation process is to derive Tax location at a time of Capitalization and /or 
Transfer of an Asset. 

Currently this process is in two part, one for non-US countries and other for the US. 

Based on Input fields, location derivation process sequentially go through conditional checks until Location is 
derived. Once the Tax Location is derived, process returns to calling controller/process the tax Location Code 
(TAXWARE Code). When it has been determind that an error situation has been encountered that error code will be 
set here and returned to calling process. It's calling process responsibility to check the error code and take 
appropriate action. While deriving tax Location if Work Location and Building is derived, then this process will 
return Location + Building. Also Location type will be set and returned to calling process. 

Special consideration is taken for US side of the logic, is after retrieving TXJCD and before returning to controller, 
verify TXJCD exists in Taxware to Taxloc mapping table. If TXJCD does not exists or if the taxloc field is blank, 
set ERROR Code ("TXJCD does not have matching Tax location Code"). The derived TXJCD value should be 
returned to the calling program. 



There are two path to Location derivation process, One for US and the other for all other countries. To process 
which side of Location Derivation, ABF will look in to Country Table to make determination to either to process 
EMEA or US. 



Field •:, ./ 


Valid Values 


Input/ 






Output 


Country Code 


Valid Country Code 




Location Type 


L, V, I, C 


I/O 


Usage Code 


15* 




Asset Class 


42, 41, OX, IX* 


I 


Lotcap Indicator 


YorN 


I 


Employee Serial Number 


Valid Serial 




Vendor Number 


Valid Vendor Number 





|Plant of Control 


Valid Plant of Control 


I I 


(Customer Number 


Valid Customer Number 


i i 


|Work Loc. + Building 


Valid Work Loc. + Building 


I/O 


(Ship to Zipcode 


Valid Shiptozipcode 


i 


[Loaner Number 


Valid Loaner Number 


i 


[Responsible Cost Center 


Valid RCC 


I/O 


[Ordering Cost Center 


Valid Cost Center 


■ 


|Profit Center 


Valid Profit Center (PRCTR) 




[Warehouse Number 


Valid Warehouse # 




[Owner Type for Warehouse Lookup WDC or WH* | I 


|Taxw Code(TXJCD) 


Valid Tax Code 


o 


Error Code 


Blank as Input/Output 

If error, Error Code will be passed back 


o 



* These are the values that are specifically used in the derivation process. 
Note: 

1) This fields are needed by itself or with conjunction with one and another for Tax Location Derivation. 



Special consideration for US Tax Location Derivation: 

1) . After retrieving TXJCD and before returning to controller, verify TXJCD exists in Taxware to Taxloc 
mapping table. 

If TXJCD does not exists, set ERROR Code for ("TXJCD does not have matching Tax location Code") 



[interim Location Derivation Process 



IfLOTCAP_IND = Yes 
Do; 

Use Ship_to_Zipcode as key to read in RESO table 
If ShiptoJZipcode found 

Retrieve TXJCD Code from RESO Table 
Set Locationjype = T /* IBM Bldg. work loc. and building */ 
Else /*** EEEERRRROOORRRR ****/ 

End; 

Else 

If Owner type = 'WH*' or 'WDC or 'PM' or 'HDC or 'SDC 
Do; 



Read Warehouse Owner Table by Warehouse Number and Country Code as key 

If Warehouse Number and Country Code found 

Do; 

Use Work. Loc. + Bldg. as key to RESO Table 
If Found 

Retrieve and Assign TXJCD from RESO Table 
Set Location Type = T 
Else /*** EEE ER R RRROOO RRRR ***/ 

End; 

Else /**** EEERRRROOOORRRR ***/ 

End; 
Else 

If Work Loc. + Bldg. NE Blank 
Do; 

Use Work Loc. + Bldg. # as key from input to read in Building (RESO) table 
If Work Loc. + Bldg. found 

Retrieve Building Information with TXJCD Code 
Set LocationType = T 
Else /*** EEERRRRROOOORRRR ****/ 

End; 
Else 

If Ordering Cost center NE Blank 
Do; 

Read CSKS by Ordering Center as Key 

If work. Loc. + Bldg. found 

Do; 

Use Work. Loc. + Bldg. as key to RESO table 
If Found 

Retrieve and Assign TXJCD from RESO Table 
Set Location Type = T 
Else 



EEEEERRRRROOOOORRRRR 



jFrocess logic below from "Interim Blue Page": 



End 
Else 

jProcess logic below from "Interim Blue Page" 



[Interim Blue Page 
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If EMPLOYEE_SERIAL NE BLANK 
Do; 

Use Country Code to see which field will be use to get to Work Loc. + Bldg. (new field on entry 



Use Emp. Serial Number as Key to read in Blue Pages 

If Emp. Serial Found 

Do; 

Use Intrim-derived_field to retrieve Work Loc. + Bldg(from workloc_bld mapping table) 
If Intrim-derived_field found 

Use Work Loc. + Bldg. from Interim table to retrieve TXJCD from RESO Table 

If Found on RESO 
Assign TXJCD from RESO 

Set Locationjype = T /* IBM Bldg. and work loc. and building */ 
Return Work. Loc. + Bldg. 
Else I* EEERRRRROOOORRRR*/ 
Else /* EEERRRRROOOORRRR*/ 

End; 
Else 



table) 



If Intrim-derived_field = blank 
Do; 



|Process logic from ' Interim B3 I i> ployei Serial 



End; 
Else 
Do; 



(Process logic from "Interim By Cost Center"! 



End; 



End; 
Else 



(Process logic from "Interim By Cost Center" 




If EMPLOYEE SERIAL NE BLANK 



Do; 

Use Emp. Serial Number as Key to read in Blue Pages 
If employeeserial found 



Do; 

Use Work Loc + Building # from Blue Pages to read in RESO Table 
IF Work. Loc + Bldg Found 



Retrieve TXJCD Code from RESO Table 
Assign TXJCD 

Set Locationjype = T /* IBM Bldg. and work loc. and building */ 
Else /** EEEEERRRRROOOORRRR **/' 
End; 

Else 

If employeeserial Not Found 
Do; 

If cost center NE BLANK 
Do; 

[Process lo gic from "Interim By Cost Center"|| 



End; 

Else 

1 1 f : 1 I I S RRRRRRROOOO< OORRRRRRRRR 

End; /* end of Employee serial not found */ 

End; /* end of Employee Serial # not Blank */ 



[interim By Cost Center] 



If cost center NE BLANK 
Do; 

-Use cost center as key to read in Bluepages table & Retrieve Mgr.'s. Serial # for cost center . 
If Mgr.'s Serial Found then 
Do; 

If In rim-derived field = Blank 

Use Work Loc. + Bldg to read RESO table 
If Found on RESO 

Assign TXJCD from RESO 

Set Locationjype = T /* IBM Bldg. and work loc. and building */ 
Return Work. Loc. + Bldg. 
Else /* EEEERRRROOOORRRR */ 

Else 

If Inrim-derived_field NE Blank 

Use Intrim-derived_field to retrieve Work Loc. + Bldg(from mapping table) 
If Intrim-derived field found 

Use Work Loc. + Building to read in RESO Table 

If Found on RESO 
Assign TXJCD from RESO 

Set Locationjype = T /* IBM Bldg. and work loc. and building */ 
Return Work. Loc. + Bldg. 

Else /* EEEERRRROOOORRRR */ 



Else/* EEEERRRRROOOOORRRRR*/ 

End; 
Else 

If Mgr.'s Serial Not Found then 
Do; 

-Use Cost Center as key to read in CSKS for Serial(NAME2) 
If Serial Found 
-Use Serial # to read Blue Pages 
Do; 

If Inrim-derivedfield = Blank 

Use Work Loc. + Bldg to read RESO table 
If Found on RESO 

Assign TXJCD from RESO 

Set Location_type = T /* IBM Bldg. and work loc. and building */ 
Return Work. Loc. + Bldg. 
Else /* EEEERRRROOOORRRR */ 

Else 

If Inrim-derived field NE Blank 

Use Intrim-derived_field to retrieve Work Loc. + Bldg(from mapping table) 
If Intrim-derivedfield found 

Use Work Loc. + Building to read in RESO Table 

If Found on RESO 

Assign TXJCD from RESO 

Set Location_type = T /* IBM Bldg. and work loc. and building 
Return Work. Loc. + Bldg. 
Else /* EEEERRRROOOORRRR */ 
Else/* EEEERRRRROOOOORRRRR*/ 

End; 

If Serial Not Found 
U £ lugst fi.jm "inici an b\ Del luit Onnu (Sei ial #) ' 



End; /* Mgr.'s Serial Not Found */ 
End;/ * cost center NE Blank */ 



(Interim by Default Owner(Serial #) 



-Use Country Code to find Default Owner in Default Owner table 

If Default Owner (Serial #) found 

Do; 

-Retrieve Default Serial # and Read in Blue Pages for Intrim-derived_field to WrkLoc.+Bldg. 
If Default Serial # Found & Work Loc. + Bldg. o Blank 
Do; 

Use Work Loc. + Bldg. as key to read in RESO Table 
If Work Loc. + Bldg. found 
Do; 

Retrieve TXJCD Code 

Set Location Type = I 1 /* IBM Bldg. work Loc. */ 
End; /* end of Work Loc. + Bldg. found & TXJCD Code o Blank */ 
Else /* *EEEEEERRRRRRROOO OOOORRRRRRR *** */ 
End; /* end of Serial # found in Blue Pages & Work Loc. + Bldg. o Blank */ 
Else/* **** EEEEEERRRRRROOOOOOORRRRRRR ***/ 
End; /* end of Default Owner (Serial #) found in Default Owner Table */ 



Else/***** EEEEEERRRRRRROOOOOORRRRRRR *****/ 



Interim Process Ends 



Strategic Location Derivation Process! 



Return to Plant 



If Usagecode = '15' 

Do; /**** For Return to plant ****/ 
-Use Plant code as key to read in Plant_Of_controI table 
if Plant_of_control found & Workjoc + Bldg. o blank 
Do; 

-Retrieve Workjoc + Bldg. Number 

-Use Workjoc + Bldg. as key to read in PJESO table 

IfTXJCD Code found 

-Retrieve TXJCD Code from RESO 
-Set Location Jype = T /* IBM Bldg. and work loc. and building */ 
Else / * EEEERR R ROOOOR R R * * */ 
End; 

Else /*EEEERRRROOOORRR ***/ 
End; 
Else 



Rentals 



If ASSET JTLASS = '42' 
Do; 

Read ZACTLAREA by Landl to retrieve Country Code(i.e. 897 for US) 
if found 

Do; 

Use Country code + Input Customer Number & TXJCD o Blank 



to read in ZKNAl(by KATR6 + ZZKV-CUSNO) 

If Customer Number found & TXJCD o blank 
Do; 

Read Customer Number in ZADRC where ZKNA1-ADRNR = 
ZADRC-ADDRNUMBER and ZADRC-NATION = ' 1 
If Customer found & ((ZADRC-ROOMNUMBER and ZADRC-BUILDING) o Blank) 
Do; /* Internal */ 

Retrieve Work Loc, Building 
Go to ZARESO to retrive TXJCD 
Set Location type = T 
End; 
else 
Do; 

Do; /* External */ 

Retrieve KNA1 -TXJCD 
Set Location type = 'C 
End; /* external */ 
End; /* If work Loc + Bldg was blank on MPP */ 
End; /* if customer found in MPP */ 

Else/* Customer Not found */ 
if Customer is not Found 
Do; 

Use Customer Number to read in ZACUST 
If Customer Number Found & Work Loc + Bldg o Blank 
Do; 

Use Work Loc + Bldg to read in ZARESO 
If Work Loc + Bldg found in ZARESO 
Do; 

Retrieve TXJCD 
Set Location type = T 
End; 

Else/**** ERROR***/ 

End; 

Else 

|eeeeeerrrrrrooooorrrrr| 



END; /* end of customer not found or TXJCD code is blank */ 

End;/* ZACTLAREA - Country Code found */ 
Else 

/**** EERRRROOORRR Country Code Not found ****/ 
End; /* end of Asset class 42 */ 

Else 



(All Lotcaps 



IfLOTCAP_IND = Yes 

Do; /***** For Lot cap *****/ 

Use Ship_to_Zipcode + Profit Center as key to read in Ship_to_Zip table 
IF Record Found 
Do; 

Retrieve Work Loc. + Building Number 
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Based on Work Loc. + Building Number, read in RESO table to (Possibly direct read of 
RESO by ZIP Code & Profit Center) retrieve TXJCD Code from RESO Table 
Set Location_type = T /* IBM Bldg. and work loc. and building */ 
End; 



End; 
End; 



;V\ arc-house j 



If Owner_type = WDC* or WH* or PM* or HDC* or SDC* 
Do; 

Read Warehouse Owner Table by Warehouse Number and Country Code as key 

If Warehouse Owner Number and Country Code found 

Do; 

Use Work. Loc + Bldg as key to RESO Table 
IfFound 

Retreive and Assign TXJCD from RESO Table 
Set Location Type = T 
Else /*** EEEERRRRROOORRRR ***/ 

End; 

Else /**** EEERRRROOOORRRR ***/ 



If ASSET_CLASS = OX* or IX* 

Do; /***** Buildings & Land *****/ 

Use Work Loc. + Bldg. # as key from input to read in RESO table 
If Work Loc. + Bldg. found & TXJCD Code is <> Blank 

Retrieve TXJCD Code from RESO table 
Set Locationjype = T /* IBM Bldg. */ 
Else /* * * * * EEEEEERRRRRROOOOOOR RRRRRR ***** */ 
End; 



Else 



Do; 




End; 
Else 



[Land & Building j 



Else 



[Property Control (Web Front-end) 



If LOCATIONTYPE = 'L'/'V'/'I'/'C 
Do; 

IF 'V /**** Location For Vendor ****/ 
Do; 

Use Vendor Number as key from input to read in Vendor Table 
If Vendor Number found & TAXAWARE Code is <> Blank 

Retrieve Vendor Information, with TXJCD Code 
Else /*** EEEEERRRRRROOOOOORRRRRR***/ 
end; 

If'L' /**** Location For Loaner ****/ 
Do; 

Use Loaner Number as key from input to read in Loaner Table 
If Loaner Number found & TXJCD Code is o Blank 

Retrieve Loaner Information, with TXJCD Code 
Else /*** EEEEERRRRRROOOOOORRRRRR***/ 
end; 

If 'C /**** Location For customer # ****/ 
Do; 

Do;/***** ****/ 

Read ZACTLAREA by Landl to retrieve Counfry Code(i.e. 897 for US) 
if found 

Do; 

Use Country code + Input Customer Number & TXJCD o Blank 
to read in ZKNAl(by KATR6 + ZZKV-CUSNO) 

If Customer Number found & TXJCD <> blank 

Do; 

Read Customer Number in ZADRC where ZKN A 1 - ADRNR = 
ZADRC-ADDRNUMBER and ZADRC -NATION = ' ' 
If Customer found & ((ZADRC-ROOMNUMBER and ZADRC-BUILDING) o Blank) 
Do; /* Internal */ 

Retrieve Work Loc, Building 
Go to ZARESO to retrive TXJCD 
Set Location type = T 

End; 
else 
Do; 

Do; /* External */ 
Retrieve KNA1 -TXJCD 
Set Location type = 'C 
End; /* external */ 
End; /* If work Loc + BIdg was blank on MPP */ 
End; /* if customer found in MPP */ 
Else/* Customer Not found */ 
if Customer is not Found 
Do; 

Use Customer Number to read in ZACUST 
If Customer Number Found & Work Loc + Bldg o Blank 

Do; 

Use Work Loc + Bldg to read in ZARESO 
If Work Loc + Bldg found in ZARESO 
Do; 
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Retrieve TXJCD 
Set Location type = T 

End; 

Else/**** ERROR***/ 
End; 

Else 

| EE E E E E R RRR R R O O O O O RRRRR I 



END; /* end of customer not found or TXJCD code is blank */ 

End;/* ZACTLAREA - Country Code found */ 
Else 

/* * * * EERRRROOORR R Country Code Not found * * * */ 

end;/* End of Location type = C */ 

If T /* * * * Work Loc + Bldg Lookup Lo g ic */ 
Do; 

Use Work Loc. + Bldg. # as key from input to read in Building (RESO) table 
If Work Loc. + Bldg. found & TXJCD Code is o Blank 

Retrieve Building Information with TXJCD Code 
Else/* * * EEEEERRRRRROOOOOO RRRRRR* * */ 
end; 

End; 

Else 



ll>P Equipment! 



Ilf ASSET_CLASS = '41' 

Do; /***** For DP Equipment****/ 

If customer number NE BLANK 
Do 

Read ZACTLAREA by Landl to retrieve Country Code(i.e. 897 for US) 
if found 

Do; 

Use Country code + Input Customer Number & TXJCD o Blank 
to read in ZKNAl(by KATR6 + ZZKV-CUSNO) 

If Customer Number found & TXJCD <> blank 

Do; 

Read Customer Number in ZADRC where ZKNA1-ADRNR = 
ZADRC-ADDRNUMBER and Z AD RC-N ATION = ' ' 
If Customer found & ((ZADRC-ROOMNUMBER and ZADRC-BUILDING) o Blank) 
Do; /* Internal */ 

Retrieve Work Loc, Building 
Go to ZARESO to retrive TXJCD 
Set Location type = T 

End; 
else 
Do; 

Do; /* External */ 
Retrieve KNA1 -TXJCD 
Set Location type = C 
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End; /* external */ 
End; /* If work Loc + Bldg was blank on MPP */ 
End; /* if customer found in MPP */ 
Else/* Customer Not found */ 
if Customer is not Found 
Do; 

Use Customer Number to read in ZACUST 
If Customer Number Found & Work Loc + Bldg o Blank 
Do; 

Use Work Loc + Bldg to read in ZARESO 
If Work Loc + Bldg found in ZARESO 
Do; 

Retrieve TXJCD 
Set Location type = T 

End; 

Else /**** ERROR***/ 
End; 

'i roccss logic t>ck v> I nni P> Employee >nai '*" J 



END; /* end of customer not found or TXJCD code is blank */ 

End;/* ZACTLAREA - Country Code found */ 
Else 

/**** EERRRROOORRR Country Code Not found ****/ 

END/* Customer NE Blank */ 
Else 

If employee serial NE BLANK 
Do; 

[Process logic below from "By Employee Serial #" 



End; 
Else 

If cost center NE BLANK 
Do; 

Process logic below from "Cost Center(Dept)" 



End; 

Else /**** EEERRROOOORRRR ****/ 
END; 
Else 



[Vendor Number] 



If Vendornumber o = ' ' 
Do; 

-Use Vendor Number as key from input to read in Vendor Table 
If Vendor Number Found & TXJCD Code is o Blank 



-12- 



-Retrieve Vendor Information with TXJCD Code 
-Set Location_type = ' V /* Vendor */ 
Else 

[Process logic below from "By Employee Serial #" | 



END; 
Else 



Loaner Number! 



If Loanernumber o = ' ' 
Do; 

-Use Loaner Number as key from input to read in Loaner Table 
If Loaner Number Found & TXJCD Code is o Blank 

-Retrieve Loaner Information, with TXJCD Code 

-Set Location_type = 'L' /* Loaner */ 
Else 

[process logic below from "By Employee Serial #" 



END; 
Else 



[Work Location & Building 



If Work Ioc. + BIdg. num. <>= ' ' 
Do; 

-Use Work Loc. + Bldg. # as key from input to read in Building (RESO) table 
If Work Loc. + Building Found & TXJCD Code is o Blank 

-Retrieve TXJCD Code from RESO 

-Set Locationjype = T /* IBM Bldg. */ 
Else 

jProcess logic below from "By Employee Serial #" 



END: 
Else 



(By Employee Serial Number!) 
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If EMPLOYEESERIAL NE BLANK 
Do; 

If employee serial found 
Do; 

Use Emp. Serial Number as Key to read in Blue Pages 

Use Work Loc + Building # from Blue Pages to read in RESO Table 

IF Work. Loc + Bldg Found 

Retrieve TXJCD Code from RESO Table 

Assign TXJCD 

Set Location_type = T /* IBM Bldg. and work loc. and building */ 
Else /** EEEEERRRRROOOORRRR **/ 
End; 

Else 

If employee serial Not Found 
Do; 

If cost center NE BLANK 
Do; 

-Use cost center as key to read in Bluepages~> Mgr.'s. Serial 
If Mgr.'s Serial Found then 
Do; 

Use Work Loc + Building # from Bluepages to read in RESO Table 
Retrieve TXJCD Code from RESO Table 
Set Locationjype = T /* IBM Bldg. Work Loc. */ 
End; 
Else 

If Mgr.'s Serial Not Found then 
Do; 

-Use Cost Center as key to read in CSKS for Serial 
If Serial Found 

-Use Serial # as Key to read in Blue Pages for Work Loc. + Bldg. 
-If Work Loc. + Bldg. found in Blue Pages 

Use Work Loc. + Bldg. as key to read in RESO Table 
If Work Loc. + Bldg. Found & TXJCD Code o blank 
Retrieve TXJCD Code 

Set Location Type = I' /* IBM Bldg. work Loc. */ 
Else 



Use Country Code to find Default Owner(Serial #)->Blue Pages — > Work. Loc+Bldg — >RESO~>TXJCD 
If Not Found /*** ERROR**/ 



Else 



Use Country Code to find Default Owner(Serial #)--> 
Blue Pages -- > Work. Loc+Bldg — >RESO ->TXJCD 
If Not Found /*** ERROR**/ 



If Serial Not Found 



-Use Country Code to find Default Owner(Serial #)-->: 
Blue Pages — > Work. Loc+Bldg — >RESO->TXJCD 
If Not Found /*** ERROR**/ 
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End; /* Mgr.'s Serial Not Found */ 
End;/ * cost center NE Blank */ 
Else 

[Process logic below from "By Customer Number"(When Cost Center is Blank ) : \ 



End; /* end of Employee serial not found */ 

End; /* end of Employee Serial # not Blank */ 

Else 



[By Customer Number! 



Ilf Customer NUMBER NE BLANK 
Do 

Read ZACTLAREA by Land! to retrieve Country Code(i.e. 897 for US) 
if found 

Do; 

Use Country code + Input Customer Number & TXJCD o Blank 
to read in ZKNAl(by KATR6 + ZZKV-CUSNO) 

If Customer Number found & TXJCD <> blank 

Do; 

Read Customer Number in ZADRC where ZKNA1-ADRNR = 
ZADRC-ADDRNUMBER and ZADRC -NATION = ' * 
If Customer found & ((ZADRC-ROOMNUMBER and ZADRC-B UILDING) o Blank) 
Do; /* Internal */ 

Retrieve Work Loc, Building 
Go to ZARESO to retrive TXJCD 
Set Location type = T 

End; 
else 
Do; 

Do; /* External */ 
Retrieve KN A 1 -TXJCD 
Set Location type = 'C 
End; /* external */ 
End; /* If work Loc + Bldg was blank on MPP */ 
End; /* if customer found in MPP */ 
Else/* Customer Not found */ 
if Customer is not Found 
Do; 

Use Customer Number to read in ZACUST 
If Customer Number Found & Work Loc + Bldg o Blank 
Do; 

Use Work Loc + Bldg to read in ZARESO 
If Work Loc + Bldg found in ZARESO 
Do; 

Retrieve TXJCD 
Set Location type = T 
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End; 

Else/**** ERROR***/ 

End; 

Else 



Use Country Code to find Default Owner(SeriaI #)--> 
Blue Pages — > Work. Loc+Bldg — >RESO->TXJCD 
If Not Found/*** ERROR**/ 



END; /* end of customer not found or TXJCD code is blank */ 

End;/* ZACTLAREA - Country Code found */ 
Else 

/* * * * EERRRROOORRR Country Code Not found * * * */ 

End; 

Else 

|By Cost Center (Deptl 



If cost center NE BLANK 
Do; 

-Use cost center as key to read in Bluepages table & Retrieve Mgr.'s. Serial # for cost center . 
If Mgr.'s Serial Found then 
Do; 

Use Work Loc + Building # from Bluepages to read in RESO Table 
IF Work. Loc + BIdg Found 

Retrieve TXJCD Code from RESO Table 
Assign TXJCD 

Set Locationjype = T /* IBM Bldg. and work loc. and building */ 
Else /** EEEEERRRRROOOORRRR **/ 

End; 
Else 

If Mgr.'s Serial Not Found then 
Do; 

-Use Cost Center as key to read in CSKS for Serial 
If Serial Found 

-Use Serial # as Key to read in Blue Pages for Work Loc. + Bldg. 
-If Work Loc. + Bldg. found in Blue Pages 

Use Work Loc. + Bldg. as key to read in RESO Table 
If Work Loc. + Bldg. Found 
Retrieve TXJCD Code 

Set Location Type = I' /* IBM Bldg. work Loc */ 
Else 

I/* * * EE EERRRRROOOOORRRRR R* **/ 1 



Else; 

If Serial Not Found 

-Use Country Code to find Default Owner in Default Owner table 
If Default Owner (Serial #) found 
Do; 

-Retrieve Default Serial # and Read in Blue Pages 

If Default Serial # Found & Work Loc. + Bldg. o Blank 
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Use Work Loc. + Bldg. as key to read in RESO Table 
If Work Loc. + Bldg. found & TXJCD Code o blank 
Do; 

Retrieve TXJCD Code 

Set Location Type = I 1 /* IBM Bldg. work Loc. */ 
End; /* end of Work Loc. + Bldg. found & TXJCD Code <> Blank */ 

Else /**EEEEEERR.RRRRROOOOOOORRRRRRR *** */ 
End; /* end of Serial # found in Blue Pages & Work Loc. + Bldg. o Blank */ 
Else/* **** E EEEEERRRR R R OOOOOOO R R R R R R R ***/ 
End; /* end of Default Owner (Serial #) found in Default Owner Table */ 
Else /***** EEEEEERRRRRRROOOOOORRRRRRR ***»*/ 
End; /* Mgr.'s Serial Not Found */ 
End;/ * cost center NE Blank */ 



Else 



/***** If Non of Above condition * 
* EEEEERRRRROOOORRRRR 



** Location Type is needed for input type: WEB front-end 

|Loc. type Ind. (Location Type 

|v [Vendor • 

[c |Customer 

|L jLoaner 

[i [Building (IBM 



Fields needed from Z tables for Location Derivation Process are included in the attached document along 
with other new/changed Z tables fields: 
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Status In Review 



CR520 Linlc To synchronize field descriptions in ECF 
See Vinny's document Link for field descriptions 



Release 2.2 Notes: 

There are no changes associated with ECF for the Retirement Controller. I added the Retirement Overview 
details. For some reason, this was not in or it was removed from the original document. (NQVfiSHM) 

New fields have to be created for Capitalizations 

For Transfers new fields have been added . CV«9gSHfc 

OPEN ITEMS: 



The field names shown below for detail page of Capitalizations are the re) 2.1 field names. They should be 
changed to the common descriptions stated in CR520. 



The Error Correction Facility (ECF) is a common set of functions for handling errors generated during the 
processing of inbound bridges. Errors detected by the bridge programs will be routed to ECF for 
correction/resubmission by accounting center users. 

The types of errors that this facility Would handle are ones that occur within individual input records. If an entire 
file is in error due to invalid control totals*or other problems with the file the entire job will fail and be handled via 
the job scheduling process, not ECF. 

It is important to understand that the way errors will be handled and reprocessed is dependent upon the point within 
the bridge processing the error originated from. Inbound bridge processing is made up of two distinct phases. The 
first part takes the input data and generates one or more SAP transaction structures from it, fully populated with all 
the data. This first part is called a Process Controller. Validations are performed in the Process Controller as well as 
table lookups which get data not provided in the input record. The second part processes the transaction structures 
into SAP, one at a time. The second part is called the Transaction Controller. 

If an error is detected in the Process Controller, the input structure plus any derived data elements are written to 
ECF. Once the problem is corrected the data is input back into the Process Controller and rerun from the beginning 
of the controller. The transaction structures are rebuilt from the input structure. 

If an error is detected in the Transaction Controller or in one of the transactions it calls, all of the transactions are 
written to ECF. The transaction will have result/error codes with them so that it can be determined which 
transactions successfully processed, which one failed, and which have not run yet. If SAP has been updated by at 
least one of the transactions, error handling is more complex because SAP is left partially updated. The completed 
transactions cannot be rolled back. The Process Controllers cannot handle a rerun of these incomplete records 
unless specific logic is built in for each situation. Rather than incorporate into all the bridges additional logic to 
handle resubmitting the incomplete ECF records, ECF will bypass the Process Controllers and reprocess the errors 
as SAP transactions back into the Transaction Controller. The Transaction Controller will use the result/error codes 
to determine which transactions to process. 

Components 

Insert Errors to the ECF Table 

All controllers will call a function to insert errors to the ECF tables. The function inserts one process controller 
record or one transaction record each time it is called. If there are a set of transactions to be inserted, the insert 
function is called once for each transaction. 

In addition to inserting the record into the ECF tables, the record is inserted into the corresponding audit trail table 
as well. This record is never changed and will remain as an original copy of the record. 

Dialog to View/Change Error Records 

Maintenance dialogs generated by SAP will be used to view/update ECF data. From these dialogs, users can modify 
individual records, select records to view/update, and perform a mass change against selected records. Creating on- 
line or printed reports with the flexibility to select records, fields, sort sequence and report format is also available 
from the maintenance dialogs. ' " * 

Purging records will be enabled by a user changing the status field on the record to a "P". When the next ECF batch 
cycle runs, all "P" records will be deleted from the ECF tables and moved to the audit trail tables. 

% 

Reprocessing of Errors 

Batch programs will extract records from the ECF tables and resubmit the data to the Process Controller or 
Transaction Controller. The batch programs will support selecting all ECF records for reprocessing or just those 
with a status of "corrected." If another error occurs on a record that has been resubmitted, the record in ECF is 
updated with the new error message. If the record is successfully processed the new record is moved to an audit trail 
table and the original record is deleted from the ECF table. 



Archive Process 

An archive process is used to reduce the amount of data being stored in the ECF Audit Trail tables. Records will be 
selected to be archived and be removed from the table and put into files to be stored for historical purposes. It is not 
expected that users will use the archived data in MVS very much. 



Audit Trail 

Audit trail tables will contain a copy of the original and corrected records. The audit trail table is populated with 
the original record when the error is first inserted into ECF. After the corrected record has been successfully 
reprocessed into SAP it is deleted out of the ECF table and inserted into the audit trail table. 

Authorization 

Authorization will be set up using standard SAP authorization objects and groups. There is one authorization group 
per table or related groups of tables. From these profiles, on-line ECF processing is able to perform the following 
validations and processing. 

• Determine if a user has no access, read access, or update access to the table they selected. 

• Select and allow access to the data for only the country or countries defined in the authorization project. 

Users will be granted either read or update access to specific ECF tables and countries. Authorizations based on 
specific fields is not provided. If a user has access to a table they can view/change the entire record. Certain fields 
in a record are display only, but they will be display only to all users. 



Assumptions 

SAP authorization objects and profiles will be defined outside the scope of this PFS. 

The structures of the various transactions can be found in the AD Design documents or in SAP. 
ECF Error Tables 

Errors are stored in SAP user defined tables (commonly called Z-tables). All tables are client dependent. Each 
unique data format is stored in a separate table. The tables have two logical parts. One contains the data in common 
across all records. These are key fields, control information, error message, machine type and serial, etc. The other 
part of the table contains the data specific to the particular record format. The elements making up the common part 
of the tables are listed here. The table name of each of the individual formats is listed after the common fields. See 
the table layout in the SAP data dictionary for the fields/field sizes of each of the tables via transaction SE1 1. 

Common Data Fields 



• Client 

• Country 

• Feeder Source Code 

• Bridge Sequence Number 

• Bridge Record Number 



■• • Transaction Sequence Number 

• Status 

• SAP SubRC 

• SAP Message Type 

• SAP Message Identification 
'' • SAP Message Number 

• SAP Message Text 

• SAP Message Variable 1 

• SAP Message Variable 2 

• SAP Message Variable 3 

• SAP Message Variable 4 

• Original Run Date 

• Original Run Time 

• Change Date 

• Change Time 

• Change Userid 

• ECF Completion Date 

• Process Type 

• SAP Transaction Code 

Process Controller and Transaction Specific Data Formats 



The following table contains a list of the individual data formats supported in ECF. Each of the formats in the table 
bf ■J have an associated audit trail table and creen tot c u h table. 



[Data Format 


SAP Table Name 


. Transaction Description 


(Capitalization Controller 


ZATECFCAPS 


Capitalizations 


•|Transfer Controller 


/ TECFTFRS 


[Transfers 


jRetirement Controller 


[ZATECFRETS 


[Retirements 1 


[Project Controller 


ZATECFPROJ 


[Projects 


|abav 


... 


ZATECFABAV 




ABUM 


|ZATECFABUM 


|Transfer 


[abzk 




ZATECFABZK 


|FI Posting 


|abzu 




ZATECFABZU 


[Write-up of special depreciation 


AMTS 




ZATECFAMTS 


[Amounts for ABZK postings, linked 



-4- 







to an ABZK for intercompany | 


AS01 


ZATECFAS01 


CreLTsset Master 


AS02 i 


ZATECFAS02 


Update Asset Master 


AS1 1 ; 


ZATECFAS1 1 




FBOl 


ZATECFFB01 


FI Posting ■ 


FB08 


ZATECFFB08 


FI Reversal 






Create Internal Order 


KO02 


ZATECFKO02 




KOH1 ! 


ZATECFKOH1 


r^^^^7^jf~~ 


KOH2 i 


ZATECFKOH2 


Update Order Group 


FMZ1 


ZATECFFMZ 1 


Create Funds Reservation 


FMZ2 


ZATECFFMZ2 


Update Funds Reservation 


FMZ4 ; 


ZATECFFMZ4 


Reduce Funds Reservation 


OIPC 


ZATECFOIPC 


Insert PCF Delta Transactions into 
ECF 


K022 


ZATECFK022 


Update Budget 



Depreciation Areas Table 

In the cases where an AS01 or AS 1 1 transaction is stored in ECF, the depreciation data extracted from the 
ZAASSETCLS table (depreciation area, useful live, period and calculation key) is stored in a separate table. The 
table supports a variable number of rows of depreciation data per AS01/AS1 1 transaction. The keys of the table 
provide linkage to a specific AS01 or AS 1 1 transaction. Since it is directly linked to other ECF tables, it does not 
contain many of the common data fields contained in the other tables. A sequence number is used to provide a 
unique key for each row. The table name for this table is ZAECFDEPR. There is no audit trail table or screens to 
access the depreciation area. SE16 or SE17 can be used to view the table when necessary. 

Posting Amounts Table 

In the cases where an ABZK transaction which is part of an intercompany transfer is stored in ECF, as many as 15 
amounts for each depreciation area can be part of the ABZK transaction. These amounts are stored in a separate 
table. The table supports a variable number of rows of amount data per ABZK transaction. The keys of the table 
provide linkage to the specific ABZK transaction. Since it is directly linked to other ECF tables, it does not contain 
many of the common data fields contained in the other tables. A sequence number is used to provide a unique key 
for each row. The table name for this table is ZATECFAMTS. While this table is structured the same way as the 
depreciation areas table, note that it does have an audit trail table. SE16 or SE17 can be used to view the table when 
necessary. 

Audit Trail Tables 

The audit trail tables are identical to the corresponding ECF tables and contain the original and corrected record 
once the record has been successfully processed into SAP. The layout is the same for the audit trail table except the 
status is a part of the key. All SAP tables must have a unique key and that status will make the original and 
corrected records have different keys. The depreciation area table does not have a corresponding audit trail table. 



Error Messages 



The SAP error message table is used to hold the error messages. Message class ZA has been defined for the Fixed 
Assets user defined messages. This table has multiple language capability. 



The following diagram illustrates the overall flow of the ECF process. Included in the diagram are control points, 
highlighted in red. Following the diagram is a description of the control points. 

Below the diagram and control points are descriptions of each of the ECF functions. The functions are grouped into 
five major parts, the red shaded box representing the function to insert errors, the computer terminal representing the 
dialog screens, the blue shaded boxes representing the reprocessing of errors, and the green shaded box representing 
the archiving of audit trail information. 



Control 
Points 


Specific 
Control 
Point? 


Description 




No j 


• Authorizations. 


ECFC2a 




• Authorization by Country 1 


ECF4M 


Yes 


• An audit tat il li jpj very record iginal and final) plus the persoi 10 last changed it 


|ECF3b1 




• Bridge program startup: for regular runs do a sequence check and verify that bridge status = 'not run'. \ 
For restarts do a sequence check and verify that bridge status = 'run'. \ 


ECF3b2 


Yes 


• An ASCA report should provide ASCA totals. ASCA totals must be compared to details created by bridge. After j 
ASCA program completion (good counts) the sequence number should be updated and the status set to 'not run'. 


ECF3c! 


Yes 


• Archive process startup: for regular runs verify that bridge status = 'not run'. For restarts verify that bridge status 


ECF3b3 


Yes 


• An ASCA report should provide totals for the ECF archive process. The report should include counts of the 
records in each of the tables before and after the archive is am tied out against the number of records extracted and 
archived. 


ECF3c3 


Yes j 


• A control record is put on the top of the outbound archive file. 



Function BF10 is called by any controller that needs to write records to the ECF error tables. In cases where a 
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controller must write multiple records, it must call this function once for each record to be written to ECF. BF10 
performs one of the following four operations based on parameters passed to it 

• Creates a new record in ECF and the ECF audit tables. This is for the case when an error is first produced 
by the bridges. 

• Update the record in the ECF table. This is for the case when an ECF reprocess of an error fails again. 
The error message and the derived fields are updated with the new values generated by the rerun. 

• Delete the record in the ECF table and insert it into the ECF audit table. This is for the case when a record 
has been successfully reprocessed and it needs to be moved to the audit trail table. 

• Delete both the ECF and audit trail record. This is for the case when a rerun of a process controller record 
makes it through the process controller, but one of the resulting SAP transactions fails. The process 
controller record is deleted from both tables and the transaction error records are inserted in its place. 



Edits/Enrichments 

The status field must contain a value in the following list 
'ECNSKRAP' 

The status field on successfully processed transactions has to be mapped to a new value based on it's original value 
in the ECF table prior to the ECF run. The following mapping occurs on all records 
[status in ECFl)rior to ECF run [New Status in ECF or ECF Audit I 

[C - Changed b\ a usei |kT- Changed by a u ei an 1 su cessfull} rerun 

i|E - Not changed by a user |r - Not changedby a user and successfully reruni 

|N - Not yet run jjS - Successfully processed on the first try [ 



Note that successfully' processed records could remain in the ECF tables in the case of transaction records. This 
happens when a transaction is successfully processed, but a subsequent transaction in the set fails. 

Dependencies 

Stable field lists for all controllers and transactions. 
Output 

ECF and ECF audit trail tables 
Exceptions, Errors & Handling 

If a failure occurs in writing to the ECF error tables the bridge program should abend. The error message should 
indicate what table and what the key of the record was at the time of the failure. ECF must be capable of restarting 
at the point of failure once the problem is corrected. 



A set of dialog screens are used to view and modify ECF records. An ECF Table Selection Screen, linked to user 
defined transaction code ZAEC, displays a list of all ECF tables. Selecting a table on this screen transfers control to 
view/update screens for that table. All view/update screens are generated by the SAP View Maintenance Generation 
Tool. The basic functions provided by the SAP generated screens are: 



Ability to view/update selected fields for a set of records on one screen, called an Overview Screen. 



• Ability to view/update all fields for one record on a single screen, called a Detail Screen. 

• Ability to select records based on the contents of any or all fields. 
'■ • Ability to purge all selected records. 

• Ability to perform a mass change on a field in all selected records. 

• Ability to dynamically create an on-line report containing any or all fields in all selected records. 

• Ability to print the report or download it to a file. 

ECF Table Selection Screen 

The ECF Table Selection screen contains a list of all ECF tables. Each table is associated with a radio button. Users 
will select one of the tables by depressing the radio button that corresponds to the table, then pressing one of the 
push-buttons. The following is a list of the push-button and their functions. 

• View - displays the entire contents of the selected table in view only mode. 

• Edit - displays the entire contents of the selected table in edit mode. 

• Selection for View - displays selected rows of the selected table in view only mode. Prior to displaying the 
contents of the table, the user can enter selection criteria in a pop-up window. 

• Selection for Edit - same as Selection for View, but in edit mode. 

• Cancel - exit the ECF Table Selection Screen. 



If any of the options other than Cancel are pressed, the Overview screen for the selected table is then displayed. 

To provide for access to data based on the country or countries a user supports, authorization objects will be needed 
to specify the country or countries to which the user has access. The table selection screen will access the 
authorization object to determine the allowable countries. Then, prior to calling the view maintenance dialog for the 
selected table, it populates the countries as selection criteria in a table passed to the view maintenance function. 
This table is used to select and present only the countries authorized. 
Overview and Detail Screens 

The SAP View Maintenance Generation Tool can generate two screens for each table. These screens are called 
Overview and Detail Screens. 

The Overview Screen generated by the SAP View Maintenance Generation Tool provides view/update capability of 
all eligible fields from the selected table and rows. The fields are presented horizontally across the screen, one row 
for each error record. This is similar to the way a spreadsheet is displayed. 

The Detail Screens generated by the SAP View Maintenance Generation Tool provides view/update on a single 
record. All fields are displayed on one screen 

Screen Customization 

To provide additional functions to the users, the generated screens/programs are customized in the following 
manner: 

. • All screens (both ECF and audit table screens) will be modified based on the data content required for each 
screen as well as formatting the screen so that all field labels and data elements are aligned into columns. 



• For the Capitalization, Transfer, Retirement, and WIP tables, a function will be executed to dequeue the 
table prior to screen display. The SAP generated code will enqueue the table whenever a user accesses it in 
write mode. Dequeuing the table will allow multiple users to access the table in write mode. 

Note: if two users are in write mode at the same time and both update the same record, the last one 
to save the data will have their changes saved. 

• Authority checks will be made to ensure the user has access to view or update the ECF table selected. 

• After a user presses "Enter" or executes any function on the screen, all rows will be checked to see if the 
row has been modified. For each modified row a "C" will be put into the ECF status field, the change 
userid field will be updated with the logon userid, and the change date and time fields will be updated with 
the system date and time. Additionally, a check will be made to see if the status field was modified by the 
user. If so, the value they entered on the screen will not be overlaid by the "C". This allows a user to 
change the "C" on a record to "P" or "E" without having it changed to "C". 

• When a user selects "Save", any row they modified since the last time they saved their data will be checked 
against the current contents of the ECF table to see if that row has been deleted from the table by another 
user or by the batch process. If so, that row will be removed from the user's session. This is done because 
the standard SAP screen functions would re-insert the row back into the table in this case. A re-insert of a 
row deleted by the batch process would make the batch process fail the next time it ran. 

The following sections list the fields displayed on the controller ECF screens by type. An * following the field 
indicates that it is non-modifiable. The transactions screens are not listed separately since they contain all fields 
passed to the transaction function module and all fields are modifiable. 



Capitalizations, including Posting to WIP 

• Country* 

• Controlling Area* 

• Feeder Source Code* 

• Bridge Sequence Number* 
. • File Record Number* 

• ECF Status 

• Original Date/Time* 

• Change Date/Time* 

• Change Userid* 
■ • Message* 

• Cap. Type 

• Machine Type 

• New Mach Type 

• Model 



New Model 



• Asset Serial (with an 'X' in position 18) 

• Fiscal Depr. Life Yrs. 

• Fiscal Depr. Life Periods 

• WT Depr. Life Yrs. 

• WT Depr. Life Periods 

• Local Language Desc. 

• English Description 

• I BM Equipment Category Replaced by Usage code 

• New/Used Indicator 

• Domestic/Foreign Indicator (hide) 

• Property Indicator 

• Responsible Cost Center 

• Employee Serial 

• Customer Number 

• Location/Building Replaced by Worklocation / Building (two fields) 

• Vendor 

• AAS Status Code 

• Contract Type 

• Quantity 

• Transaction Type 

• Posting Date 

• Asset Value Date 

• Document Date 

• Ref. Doc. Number 

• AP Reversal Ref* 

• AP IntOrd* 

• Vat percent* 

• Posting Amount* 

• Posting Sign 
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• Amount in Alt. Currency* (hide) 

• Supplier 

• Intransit LC 

• Intransit Div 

• Intransit G/L Account 

• Cost Element 

• Project 

• Sub-Project 

• Capital Investment Order 

• Order Number 

• Purchase Order Line Item 

• IGS PROJECT NUMBER 

• Ship to ZIP code 

• Loaner Number 

• externa! purchase indicator 

• Bypass Caplimit check (zzmincapo) 



Capitalizations Overview Screen 



|Country/Controlling Area |Country/Controlling Area 


jFSC 


Feeder Source Code 


|BRS 


Bridge Sequence Number 


|BR Rec. 


Bridge Record Number 


. E ' 


ECF Status 


; Ref. Doc. # 


Reference Document Number 


[Machine Iype 


Machine Type 


[Asset Serial 


tsset Serial J *r 


JCap. Inv. Order 


Capital Investment Order 


[Project 


Project 


Sub 


Sub-Project 


1c. 


Cap. Type 


|R (Rental Indicator) 


change to Usage Code 


|Posting Amount 


Posting Amount 


!° 


Debit/Credit Sign 
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[Transaction 


[Transaction Type 


|Resp. Cost Center 


[Responsible Cost Center 


|Customer # 


[Customer # 


(Employee Serial 


[Employee Serial 


|lntransit LC 


|lntransit Ledger Code 


jlntransit Div 


jlntransit Division 


[intransit Acct 


[intransit Account 


]Acct. 1 /Cost El. 


.|Account 1/Cost Element (was Line Item 1) 


[Order Number 


| Order Number 


|Asset Value Date 


[Asset Value Date 


[Posting Date 


|Posting Date 


|Orig. Run Date 


[Original Run Date 


(Change Date 


|Change Date 


|Change Userid 


|Change User ID 


| Message Text 


[Message Text 



List field info and/or flow logic for a fn module 
1 



Screen Info for S APLZAES 0011 - Viewpflege: Detailbild ZAVECFCAPS 



001 |-ECF Control Data--- 
| 

002 | | Cntry/Cont Area 
I I 

I | | Fsc/Bsn/Brn 



005 || Message 



Orig Date/Time 
ChangeDate/Time 
Change Userid 



007 | -Asset Master Dat 

008 | | Cap Type 
I 

009 | | Machine Type 

I I 

010 || Model 
I 

011 I I Asset Serial 



New Mach Type 
New Model 



Cap Usage 
New/Used Indie 
Property indie. 
ITG Skip Indie. 



Employee Serial 
Customer Number 
IGS-Project 



-12- 



FI Life/Yrs/Per 
I 

WT Life/Yrs/Per 



| Local Lang Desc 

I I 
j English Descr 



WorkLoc/Buildg 



Transact ionType 



Byp . caplim.chk 



I 

ral. date 



I 

Document Date 
I I 
Ref Doc Number 

I I 
VAT percentage 
I I 
Posting Amount 

I 

Supplie 



I 



Int LC/Div/Acct _ 
I 



Ext .pur . Indie. 



Vendor Number 
Loaner Number 
AAS Stat. Code 
Contract Type 
Quantity 



apital Tracking Data-- 

Sub-project 
Cap Invest Ord 
Lineltem 1 Acct 

Ord Nm Line Itm 



-Refei 



| Reversal reference 
| AP Order Number 
I 



2 A WECFFB 0 1 : 

field info and/or flow logic foi 



i f n module pool ' £ 



Transfers Screen 

• Country Code*/Controlling Area* 

• Feeder Source Code* 

• File Sequence Number* 

• File Record Number* 
' • ECF Status 



-13- 



• Original Run Date/Time* 

• Change Date/Time 

• Change Userid 

• Serial Number (with an 'X' in position 1 8) 

• Machine Type*( Pos. 1 -4 of Inventory Number) 

• Asset Serial* (positions 5-25 of Inventory Number) 

• Asset Val. Date . 

• Posting Date 

• To Cust Number 

• To Asset Class 

• New Inv. Number 

• ToResp Cost Centr 

• Reference Doc 

• Employee Serial 

• Vendor Number 

• Location/Building location and bldg are 2 separate fields and TXJCD field will not be an input only 
derived. 

• Local Lang Desc 

• PCF Usage Code 

• Model 

• Contract Type 

• AAS Stat Code 

• IGS project code 

• To cost center 

• Asset super # 

• Manufacturer 

• OEM Model/serial 

• Comments 

• Contractor serial # 

• Location type 



-14- 



• Work location code 

• IBM bldg # 

• Floor/Rm 

• Loaner # 



Transfer Overview Screen 



|Cntry/Con Area 


|Country/Controlling Area 


|FSC 


[Feeder Source Code 


BSN 


Bridge Sequence Number ; 


|brn 


[Bridge Record Number \ 


|ECF Status 


|ECF Status | 


:(Seria] Number 


\ Serial Number 


.[inventory Number inventory number 


ffoRespCostCentr 


s ponsibl t c in r 


|To Cust Number 


[To Customer Number j 


fTo Asser Class 


|To asset class 


|New Inv Number 


|New Inventory number 


| Asset Val. date 


|Asset value date 


[Posting date 


[Posting date 


[Reference doc. 


V^jmc document 


[Vendor Number 


[Vendor Number 


[Employee Serial 


[Employee Serial Number 




[Local Lang. Desc. [Local Language Description 


|PCF Usage Code* 


jPCF usage code** 


[Model 


Model 


|AAS Statcode 


AAS status code 


•|Contract type 


1 on tract type ! 


[Project 


[~IGS project code 


[To Cost center 


|To Cost center i 


[Location Type 


|Location type 


|Wk Loc code 


|Work Location code 


|1BM BLDG 


|lBM Building Number 


| Loaner Num 


|Loaner Number 



.10 + . . .10 +. . .30 + . . .40 + . . .50 + . . .60 + . . .70 + ... 8 0 .... + ... 90 + . .100. . 



)01 |-ECF Control Data-- 



I 004 | | ECF Status 
| 005 || Message Text 



Change Userid 



| 007 | -Current Asset Data- 

008 Serial number 

009 Inventory no . 

010 Resp CostCenter 



114 | -Transfer To Target Information-- 

)1S | | ToRespCostCentr 

)1S i j To Cust Number 

)17 I j To Asset Class 

)18 || New Inv Number 

)19 I j To Cost Center 

)20 j j To Project 



Asset val. date 
Posting date 
To Profit Ctr 
To Company Code 



-Asset/Accounting Information Changes- - 

Reference doc. 

Vendor Number 

Employee Serial 



IBM BLDG 
Location type 
Local Lang Desc 



PCF Usage Code 
Loaner Nunmber 
Model 

AAS stat code 



Contract type 



[Cty [Country ! 

[CO Area [< on i llin \re j 

JfSC : [Feeder Source Code 

|BR Seq j Bridge Sequence MuroUi 

|BR Rec [Bridge Record Number 

;[iCF Status : |ECF Status [ 

Sir' i Ni jhei I al Nu il rr 
[inventory Number~|lnventory Number 
[Transaction Type [Transaction Type 
j Asset Sub No. :|Asset Subnumber 
|Ref. Doc. Number [Reference Document Number; 
[Asset Value Date | Asset Value Date 
F. in D it< [Po ting Date 

[Revenue Amount [Revenue Amount 
[Export to Coumr [e .n Counti 
[Message Text [Message Texi j 
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Retirements Screen 

• Country Code* 

• Controlling Area* 

• Feeder Source Code* 

• File Sequence Number* 

• File Record Number* 
, • ECF Status 

• Original Run Date/Time* 

• Change Date/Time 

• Change Userid 

• Machine Type* 

■ • Machine Serial*(only positions 5-25) 

• ' Transaction Type 

• Asset Sub-Number 

• Reference Doc Number 

• Asset Value Date 
'' • Message Text* 

• ECF Compl Date 

• Serial Number (with an 'X' in position 1 8) 

• Selection Indicator* 

• Revenue Amount 

• Export to country 

• Posting Date 



Projects Screen - The same changes apply to the Audit Trail Table 

• Country Code* 

• Controlling Area* 
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• Company Code* 

• Feeder Source Code* 

• File Sequence Number* 

• File Record Number* 

• ECF Status 

• Original Run Date/Time * 

• Change Date/Time* 

• Change Userid 

• Message Text 

• Sub-project description 

• Project description 

• Project 

• Sub-project # 

• Project Type (now updateable - was not previously) 

• Cap Invest Ord 

• Order Type 

• Settlement CE 

• Release Quarter 

• Project Manager 

• Organization 

• Program 

• Responsible Cost Center 

• Estimated Start Date 

• Estimated Complete Date 

• New Sub-project # 

• Settlement CE 

• Cost Element 

• Document Type* 

• Amount 
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• Due On 

• Requisition # 

• Requisition Line item # 

• Document Date 

• Purchase Order # 

• Purchase Order line item # 

• Target Machine type 

• Complete Funds Reserv 

• Close Order* 

• Re-open Order* 

• Expense % 

• Taxability Ind*(and on transaction KOO 1 and KO02) 

• Tax Rate Code* (and on transactions KO01 and KO02) 

• Orig est cost* 

• Industry Code (and on transaction KO01 and KO02) 

• Tech/Brand (and on transaction KOO 1 and KO02) 

• Product/Family (and on transaction KOOl and KO02) 

• Tracking info* (and on transaction FMZ1 ) 

• Requester* (and on transaction FMZ1) 

• Released Budget* (and on transaction K022) 

• Order Status 

Current Detail Screen 



10 



.100. . 



. . + . .110 I 



001 



-ECF Control Data- 



002 



Cntry/Cont Area 



Orig Date/Time 



003 



Fsc/Bsn/I 



ChangeDate/Tir 



ECF Status 



;erid 



005 



Message Text 



I 

ro 3 ec 

Project desc 

I 

Project Type 
I 

Project Manager 
I 

Cosy enter 

RespCCtr 
I 

Organization 
I 

Program 
I 

" "l 

•Sub Project Data-- 
I 

Sub-proj ect 
I 

Sub proj desc 



I 

Cap Invest Ord 
I 

Order type 
I 

Estim. Start Date 
I 

Estim. Compl . Date 
I 

Release Quarter 
,1 

Estim. costs 

Target Machine 
I 

ercen 

ose orer. 

Re-open order? 
I 

Sub-project 



I 



I 

Commitments Data-- 
I 

Document date 



Req. Number 
I 

Order Number 
I 

Complete Funds? 
I 

Amount 
I 

Settlement CE 
I 



Req Nm Line Itra 
Ord Nm Line Itm 



Proposed Changes (not yet done) The same changes apply to the Audit Trail Table 
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.30 + ...40 + ...50 +...S0 + ...70 +...80 + ...90 + . .100.. 



001 l-ECP Control Data — 



I 

| Cnty/Cont Are: 

| Fsc/Bsn/Brn 

I 

| ECF Status 
| Message Text 



Orig Date/Time 
ChangeDate/Time 
Change Userid 



I 

| - Project Data 

I 

|| Project 
I 

| | Project desc 
I 

| | Project Type 
I 

| | Project Manager 

I 

| | Cost center 
I 

! | Co Code 

I 

| | RespCCtr 
I ' 

| | Organization 
I 

| | Program 

I | Industry Code 

! | Tech/Brand 

! j Product Family 



Sub Project Data 

I 

Sub-project 
I 

Sub proj desc 
I 

020 | | Cap Invest Ord 

I 

021 | | Order type 

I 

022 | | Estim. Start Date 

I 

023 || Estim. Compl . Date 

I 

024 | | Release Quarter 

025 |[ Estim. costs 

I 

026 | | Target Machine 

I 

027 | | Percent 

i 

028 | | Close order? 

I 

02 9 || Re -open order? 
I 

030 | | New Sub-project 



Order Status 



Taxability Ind 



nents Data-- 
I 

nent Type 



Tracking info 
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I 

I 034 | | Document date 
I 

| 035 | | Due on 
I 

| 036 || Req. Number 
I 

| 037 || Order Number 
I 

| 038 | | Complete Funds? 
I 

| 03 9 || Amount 
I 

| 040 || Settlement CE 
I 

| 041 | 

I 



Document Type, Order Status, Tracking info, and Requester should not be updateable 



Project Overview Screen 



jCountry/ControIling Area Country/Controlling Area 


[Company Code 


ompany Code 


; FSC 


rrt k i Sou ce i 1 


BRS 


Bridge Sequence Number 1 


[BR Rec. 


Bridge Record Numbei 


E 


ECf Status 


[Project Type 


| Project Type 


[Project 


[Project 


[Sub-project 


|Sub-project 


[Cap Invest Ord 


|Capital Investment Order 


[Order Type 


[Order Type 


:|Amount 


|Amount 


[Project desc 


|Project description 


|Sub proj desc 


|Sub-project description 


[Cost center 


Cost Center 


|Cost element 


|Cost element 


|Req. Number 


[Requisition Number 


|Req Nm Line Itm 


(Requisition Number Line item; 


[Order Number 


[Order Number 


[Ord Nm Line Itm 


Order Number Line item 


jEstim. Start Date 


Estimated Start Date 


|Estim. Compl. Date 


[Estimated Completion Date 


|Release Quarter 


|Release Quarter 


[Message Text 


(Message Text 



Requester 

Req Nm Line Itm 
Ord Nm Line Itm 
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Screen Info for SAPLZAES 0301 



-- Viewpflege: Detailbild 



ZAVECFKO01 



Fullscreen 

Current Layout 



005 j 

006 | 



ECF Control Data--- 
Cntry/Cont Area 
Fsc/Bsn/Brn/Tsn 
Status 

BusinessProcess 
Message Text 



Orig Date/Time 
ChangeDate/Time 
Change Userid 



Order Master Data-- 

Sub-project 
Order type 
Est Start Date 
Est Compl Date 
InvestProf ile 
Estim. costs 



Company code 
Resp CostCenter 
Cost center 
Profit Center 

Program 

Release Quarter 
Proj ect Manager 
Target Machine 
Transact ionCode 



Screen Info for SAPLZAES 0301 - Viewpflege: Detailbild ZAVECFKO01 
Fullscreen 



-23- 



Proposed Layout 



-ECF Control Data--- 

| | Fsc/Bsn/Brn/Tsn 

| | Status 

j | BusinessProcess 

| | Message Text 



Orig Date/Time 
ChangeDate/Time 
Change Userid 



| -Order Master Data-- 
I | Order 
| | Project 



| Order type 

| Est Start Date 

| Est Compl Date 

| InvestProf ile _ 

| Estim. costs _____ 

| Expense Part in % , 

. | j Industry Code 
| | Tech/Brand 
| | Product Family- 



company code 
Resp CostCenter 
Cost center 
Profit Center 
Organization 
Program 

Release Quarter 
Project Manager 
Target Machine 



Order Status 
Tax Rate Code 
Taxability Ind 



Screen Info for SAPLZAES 0311 - Viewpflege: Detailbild ZAVECFKO02 
Fullscreen 

Current Screen - Update Internal Order 



.10. . 



002 i 
I I 

003 | 



005 | 
'I I 

| oos I 



■ECF Control Data — 
Cntry/Cont Area 
Fsc/Bsn/Brn/Tsn _ 
Status 

BusinessProcess 
Message Text 



Orig Date/Time 
ChangeDate/Time 
Change Userid 



020 | 
I I 

021 | 



-Order Master Data-- 
Order 

Sub-project 
Order type 
Est Start Date 
Est Compl Date 
InvestProf ile 

Re-open order? 
Close order? 
Short text 



Company code 
Resp CostCenter 

Profit Center 
Organization 
Program 

Release Quarter 
Project Manager 
Target Machine 
Transact ionCode 



Fullscreen KO02 

Suggested Screen - The same changes apply to the Audit Trail Table 















. . 80 . . . 


. + . . .90. . . . + . .100. . | 










1 ooi 1 

| 002 | 












| Cntry/Cont Area 

1 






Orig Date/Time 




1 003 1 


| Fsc/Bsn/Brn/Tsn 


1 




ChangeDate/Time 




| 004 | 


1 

Status 

1 






Change Userid 




1 005 1 


| BusinessProcess 


1 








| 006 | 


.1 1 

| Message Text 
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__>l I 

I 007 |- 



| 007 






| 008 


| 




| 009 


| 

| Order 

1 1 


Company code 


| 010 


Project 

1 1 


Resp CostCenter 


| Oil 


| Sub-project 


Cost center 


| 012 


1 1 

| Order type 

1 1 


Profit Center 


| 013 


Est Start Date 

1 1 


Organization 


| 014 


| Est Compl Date 

1 1 


Program 


| 015 


| InvestProf ile 


Release Quarter 


| 016 


1 1 

| Estim. costs 

1 1 


Project Manager 


1 ,017 


| Expense part in % 

1 1 


Target Machine 


| 018 


| Re-open order? 

1 1 


TransactionCode 


| 019 


| Close order? 


Taxability Ind 


| 020 


1 1 

| Order Status 

~ 1 1 

| Industry Code 

1 

j Tech/Brand. 

I 

| Product Family 


Tax Rate code 


| 021 


1 

| Short text 




| 022 


1 1 




1 





Screen Info for SAPLZAES 0161 - Viewpflege: Detailbild ZAVECFFMZ1 
Fullscreen 

Current layout of Screen (old CJOl) 

I 

| + ...10 + ...10 + ...30 + ...40 + ...50 + ...S0 + ...70 + ...80 + ...90 + ..100.. 

I 



| 001 |-ECF Control Data 

| 

| 002 || Country Orig Date/Time 
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I I Fsc/Bsn/Brn/Tsn 
| | Status 
| | BusinessProcess 
| | Message Text 

| 

| -Commitment Data 

| | Project _ 

| | Sub-project 

| | Text _ 
| | Document date _ 

| | Company code 

|| Order 

| | Cost element 

| | Amount 

| j Due Date 

| 1 Cost center _ 



ChangeDate/Time 
Change Dserid 



Screen Info for SAPLZAES 0161 - Viewpflege: Detailbild ZAVECFFMZ1 



Fullscreen 

Proposed layout of Screen 



The same changes apply to the Audit Trail Table 



j 00 2 || Country/Cont Area 
II 

03 | | Fsc/Bsn/Brn/Tsn 



| | BusinessProcess 
| | Message Text 



Orig Date/Time 
ChangeDate/Time 
Change Oserid 



| -Commitment Data-- 

|| Project 

| | Sub-project 
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036 
037 



| | Reg. Number 
| | Order. Number 

Order Type 



Reg Nm Line Itm 
Ord Nm Line Itm 



Type 
Document date 
Company code 

Cost element 

Cost center 
Tracking info 
Requester 



Document Type, Tracking info, order type and Requester should not be updateable 
Screen Info for SAPLZAES 0171 -- Viewpflege: Detailbild ZAVECFFMZ2 
Fullscreen 

Current Layout (CJ02) 



l-ECF Control Data--- 
I 

| | Country 

| | Fsc/Bsn/Brn/Tsn _ 

| | Status 
I 

| | BusinessProcess 

| | Message Text 

I- 

I 

| -Commitment Data 

| | Project 

| | Sub-project 



Orig Date/Time 
ChangeDate/Time 
Change Userid 
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1 1 Text 

I I Document number 

| | Document item 

| | Company code 

| [ Overall amount 

| | Complete Funds? 

| | Due on 



Screen Info for SAPLZAES 0171 - Viewpflege: Detailbild 



ZAVECFFMZ2 



Fullscreen 
Proposed Layout 



The same changes apply to the Audit Trail Table 



-ECF Control Data- 

| | Country/Cont Area 

| | Fsc/Bsn/Brn/Tsn 

| | Status 

I | BusinessProcess 

| | Message Text 



Orig Date/Time 
ChangeDate/Time 
Change Userid 



| -Commitment Data-- 
| | Project 



j | Document Type 



| | Document item 
| | Company code 

Overall amount 
| | Complete Funds? 



Req Nm Line Itm 
Ord Nm Line Itm 



II 
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I 019 | 

Document Type and order type and amount should not be updateable 

Screen Info for SAPLZAES 0141 - Viewpflege: Detailbild ZAVECFFMZ6 

Fullscreen (old CJ04) 



.10. ...+ .. .10. ... + .. .30 + ...40 + ...50. ... + .. .SO + ...70. ...+ .. .80 + ...90.. .. + ..100.. 



101 [-ECF Control Data 

■ I 

| 002 | | Country Orig Date/Time 

I I 

003 | | Fsc/Bsn/Brn/Tsn ChangeDate/Time 

I I 

0 04 || Status Change Userid 
II 

005 | | BusinessProcess 

I I 

00S || Message Text 

007 -- 

-Committment Data 

| Company code 

| Document item 

| | Document number 

! I 

)12 | | Document Date 

1 I 

)13 | | Compln ind. 
I 

)14 | | ReversalAmount 



Screen Info for SAPLZAES 0141 - Viewpflege: Detailbild ZAVECFFMZ6 



Fullscreen 

Proposed Layout '- The same changes apply to the Audit Trail Table 

I 

| +...10 +...10. ...+ .. .30 + ...40 +...50 + ...60 +. . .70. . . ^ 

I 
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-ECF Control Data 




| 001 






| 002 
1 1 


| Country/Cont Area 


Orig Date/Time 


| 003 

r i 


| Fsc/Bsn/Brn/Tsn 


ChangeDate/Time 


| 004 


| Status 


Change Userid 


1 

| 005 


[ BusinessProcess 




I I 


| Message Text 


>l 1 


| 007 




| 008 




| 009 

■1 


| Company code 




| 010 






1 1 

| 037 


| | Order Number 


Ord Nm Line Itm 


| on 


1 

| Document number 




| 012 | | Document Date 




| 013 


| Compln ind. _ 




| 014 | | ReversalAmount 




I- 1 

| 015 | | Redn text 




| 01S 

... 











Proposed Layout Transaction K022 - The same changes apply to the Audit Trail Table 



001 | -ECF Control Data 

002 | | 'Country/Cont Area _ Orig Date/Time 

II 

003 | | Fsc/Bsn/Brn/Tsn ChangeDate/Time 

II 

004 | | Status Change Userid 
'II 

005 | | BusinessProcess 

II 

00S I I Message Text 



Order type 
Company Code 
Fiscal Year 
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Release Notes 



Release 2.2 

For Project errors from Commitments do a look-up of 'Order Type' before placing the record into ECF table and 
populate the field 'Order type' 

Reporting/Printing 

Both the overview and detail screens provide print capability. Complete flexibility in both record selection criteria 
and fields to print on the report is provided by the SAP screens. No additional function is needed. 

Input 

ECF Tables 

Edits/Enrichments 

No edits will be performed on any data modified by the user. Validations occur when the error is reprocessed. 
Dependencies 

The final list of transactions and fields supported by ECF is determined based on the final content of the controllers 
and transactions supported by inbound bridging. 

Output 

ECF Tables 

Exceptions, Errors & Handling 

Any errors that occur will generate an error message to the screen. 



Scheduled batch programs extract and resubmit the records from the ECF tables. There is one program for each of 
the Process Controller errors and one program for Transaction Controller errors. These programs select records 
based on an input parameter indicating whether to select all records or those with a status of "Corrected". 

Steps Required to Reprocess Error Records 

1 . Extract all records based on input parameter indicating whether to select all records or just changed 
records. 

o When selecting all records, the extract process must NOT select any records with a status of A 
(automatically routed to ECF by the bridge). Any records sent to ECF by a bridge program must 
not be rerun unless a user changes the status. This is done because the controller does not have the 
logic that caused the record to be bypassed and could improperly reprocess the record . 

o When selecting changed records, the extract process must select any records with a status of C 
(changed by a user) or a status of P (user wants the record purged). 
Each of the Process Controller tables/records are processed individually. The Transaction Controller tables 
are processed as a set, with a set of records being related based on country, feeder source code, bridge 
sequence number and bridge record number, thus grouping together a set of transactions which were 
generated by the same input record. When executing a "changed only" run of transaction records the 
extract program must be sure to extract the entire set of transactions, not just the one with the "Corrected" 
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status. A user will only change the transaction that was in error, but the entire set must be extracted and 
sent to the Transaction Controller for reprocessing. 

1 . For all of the records read from the ECF tables accumulate and insert into the ASCA control table the input 
record count, and if the record has a process type of "CAP", accumulate the amount also. Use the sum of 
the posting amounts in all of the records for this amount field. 

2. For each record read from the ECF tables the following processing flow is followed: 

o If the record has a "P" status, call BF10 to move the record from the ECF table to the audit trail 
table. Then insert a record in the ASCA detail table with a result of "P". 

o If the record does not have a "P" status: 

Insert a record into the ASCA detail table, leaving the result field blank. Also leave the 
order number and profit center blank so that the ASCA control report will accumulate all 
records into a single entry on the cap control report. 

" Call the associated Controller to reprocess the record. If reprocessing transactions, first 
insert a set of records with the same record number into the transaction table and call the 
Transaction Controller to reprocess the transactions. The Transaction Controller will 
bypass any transactions that have a system message number which indicates the 
transaction was successfully processed and start processing at the failed transaction. 

■ Update the appropriate ECF tables, and, if necessary, the corresponding ECF Audit tables 
to reflect the reprocessing of the transaction: 

■ If the record or records were successfully processed update the message fields to 
indicate successful completion and move the record from the ECF tables to the 
ECF Audit tables. 

■ If reprocessing a Process Controller record and it failed again in the Process 
Controller, or if reprocessing transactions and one of the transactions failed 
again, then update the message and the derived fields in the ECF tables to reflect 
the new message and status for each transaction. 

■ If reprocessing a Process Controller record and it then fails in the Transaction 
Controller, delete the Process Controller record and insert the transaction 
records in the ECF tables. The record should also be deleted out of the 
appropriate Process Controller Audit Trail table. 

3. Once processing is complete on all selected ECF records, schedule the ASCA control report programs to 
create the control reports from the ASCA tables. 



The following design documents can be referenced to determine how to call the various bridge functions needed by 
the ECF Controller. 

• Capitalization Controller 

• Transfer Controller 

• Retirement Controller 

• Project Controller 

• Transaction Controller 
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Exceptions, Errors and Handling 

• If the ECF table cannot be read, an error should be generated to the SAP job log and the program 
terminated. 

• If any of the ECF or ASCA tables cannot be updated after successful completion of the record into SAP, an 
error should be generated to the SAP job log and the program terminated. All of the tables within the scope 
of a single input transaction should be updated in the same unit of work so that they stay in synch with each 
other. 

• The Controllers could also issue abends which would terminate the job. 

• Similar restart logic used by all bridges and incorporated into the common restart routine should be used for 
restarting jobs which abend. 

Source Structure 

N/A 

ASCA 

Control Reports and Control Points 

Control totals must be produced which include records extracted from ECF, records successfully completed, records 
that ended up back into ECF, and records that were purged from ECF. The corresponding Process Controller 
control report programs should be used to generate these reports. In the case of transaction errors, the control report 
for retirements should be used. 

A program is required that can be run as needed to reduce the amount of data being stored in the ECF Audit Trail 
table. To facilitate the use of this program a date will be set when the record was successfully processed into SAP 
and moved into the audit trail table. Therefore, until the record is corrected, this date will be blank. When running 
the archive process, an archive date parameter will be supplied. This parameter will be used to selectively purge 
from the ECF audit trail tables. All records corrected as of the archive date parameter to be archived. When dealing 
with transaction errors, if a record has been selected for archive all related records (records with a common ECF 
key) are selected as well. 

All records selected to be archived will be removed from the table and inserted into four separate files, one each for 
caps, transfers, retirements and transactions. Records from all of the transaction tables will be merged into the same 
file and sorted so that a set of transactions will appear together in sequence. This file should be automatically sent to 
MVS, where it can be stored for potential use. The files should be generation data sets. Each file must have a 
control header using the SAP development generic format. It is not expected that users will use the archived data in 
MVS very much. It is being stored for historical purposes. 

Archive Control Report 

A control report is required for the Archive Process. The report must provide a totals by capitalizations, transfers, 
retirements and transactions. It should indicate the total number of records present in the ECF Audit Trail Table 
before the Archive Process, the total records archived, and the total records remaining after the archive program 
has been run. For example: 

ECF Audit Trail Table Archive Process 
Date: XX/XX/XXXX 

Records Read 
Capitalization Records xxxxxx 
Transfer Records xxxxxx 
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Retirement Records 
Transaction Records 
Total Records Read 



xxxxxx 
xxxxxx 
xxxxxxx 



Records Archived 
Capitalization Records 
Transfer Records 
Retirement Records 
Transaction Records 

Total Records Archived 



xxxxxx 

xxxxxx 

xxxxxx 
xxxxxx 

xxxxxxx 



Records Remaining in Table 
Capitalization Records 
Transfer Records 
Retirement Records 
Transaction Records 
Total Records Remaining 



xxxxxx 
xxxxxx 

xxxxxx 
xxxxxx 

xxxxxxx 
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EXHIBIT D 



Disclosure RSW8-2001-0163 

Prepared for and/or by an IBM Attorney - IBM Confidential 

Created By: Diana G Hill Created On: 2:1 9:33 P M 

Last Modified By: Sim Brown Last Modified Onr^QHMBB 09:29:1 4 AM 
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Required fields are marked with the asterisk ( ) and must be filled in to complete the form . 



Title of disclosure (in English) 

" ax Local oi i Derivation Pre ess 



Summary 



Status 


Under Evaluation 




Proci 3: ing Loce tior 


RS 




functional Area 


Shander: Global Fixed Asset Process Software 




jjAttorney/Patent 
Professional 


Gregory Doudnikoff/Raleigh/IBM 




liDTTeam"" 


Gregory Doudnikoff/Raleigh/IBM 




jSubrnified Date 


^KSBBb 01:23:18 PM EOT 




J Owning 
I Division 


CHQ 




Incentive Program 


"Lab " " " " 


jTechnology Code 


PVT Score 


No PVT score has been calculated. To calculate a PVT s 


core, press the 'Calculate' button. 



Inventors with a Blue Pages entry 

Inventors: Sim Brown/Raleigh/IBM, Diana G Hill/Raleigh/IBM, Vincent Formale/Southbury/IBM 



-Inventor Name 
\> Brown, John S. (Sirn) 
| Hill, Diana 
yJp-Zsffa a te, V . (Vi Bnyjh 



Inventor . Inventor . 

Serial".-" Div/Dopt --Phone ■ - . '.Manager Name 
832529" 1Q/79QA~ " " 526-8705 Rossi, Deron J. 

858633 10/79QA 526-8701 Rossi, Deron J. 

400692 10/73BX 376-3410 Lupinacci, Ernest J. 



> denotes primary contact) 



Inventors without a Blue Pages entry 



f^f ^ ^ [(^ 7,McrL 



Dilipvatel V 

SeriaPNumber : (N/A) Company : Owns his own consulting business 

Citizenisrf: US 
E-Mail ; \ 
Business Address : 

38Q1 Gates Road 

Vestal, New York 13850 
Business Phone\.(607) 798-6244 
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RSWB-2001-0163 Tax Location Derivation Process - continued 



Home Address : 

3801 Gates Road 
Vestal, New York 13850 
(607) 729-5894 (R) 



IDT Selection 

Select Functional A 



|IDT Team: 

■ Gregory Doudnikoff/Raleigh/IBfvl 



! Attorney/Patent Professional: 

' Gregory Doudnikoff/Raleigh/IBM 



Response Due to IP&L 
*Main Idea 

1 . Describe your invention, stating the problem solved (if appropriate), and indicating the advantages of 
using the invention. 

As part of Worldwide Fixed Asset System 2.2, a new method of determining an asset's physical location 
for US tax reporting purposes was devised. This methodology relies on a series of user-maintained tables- 
that are referenced by a hierarchical program to derive an asset's physical location at the point of 
capitalization or transfer. 

2. How does the invention solve the problem or achieve an advantage,(a description of "the invention", 
including figures inline as appropriate)? 

The tax location derivation program performs a series of audits against the information included on the 
asset's incoming capitalization or transfer record. These audits check for the presence of specific 
information on the record. If that information is not found, the record is passed on to the next audit in the 
heirarchy until no additional checks can be performed. At that point, the record is sent to the error 
correction facility for manual correction by the operations team. If the audited information is found, that 
information is cross referenced against user maintained source tables to derive the asset's new tax 
location. This process of auditing and cross-referencing prevents erroneous location information from 
being added to the asset record. The previous tax location derivation often allowed incorrect location 
information to be posted to the asset record. 

3. If the same advantage or problem has been identified by others (inside/outside IBM), howhave those 
others solved it and does your solution differ and why is it better? 

Prior to the installation of this program, the derivation of an asset's physical tax location was reliant upon 
manual entries' made by each of IBM's thousands of asset owners. If the asset owners failed to input the - 
location information on a timely basis (most often the case), then a monthly back end derivation process 
was used to. assign the asset to a 'default' location. This backend process did not referencethe asset 
owner's location at all. Rather, the process relied on the department's or facility's location to determine the 
appropriate tax location of the asset. This derivation process was found to be inconsistent with IBM's 
asset ownership policies. 

4. If the invention is implemented in a product or prototype, include technical details, purpose, disclosure 
details to others and the date of that implementation. 

This tax location derivation program was implemented as part of Worldwide Fixed Asset System 2.2 on 
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|On what date was the invention workable? Wtffe Please format the date as MM/DD/YYYY 
] (Workable means i.e. when you know that your design will solve the problem) 



*Question 2 2 v 

Is there any planned or actual publication or disclosure of your invention to anyone outside ™ N 
IBM? 



If yes, Enter the name of each publication or patent and the date published below. 
Publication/Patent: 
Date Published or Issued: 



Are you aware of any publications, products or patents that relate to this invention? O Yes 

© No 



If yes, Enter the name of each publication or patent and the date published below. 
Publication/Patent: 
Date Published or Issued: 



Has the subject matter of the invention or a product incorporating the invention been sold, 
used internally in man factoring annc n ed rsale 31 n iud in roposal 



Is a sale, use in manufacturing, product announcement, or proposal planned? O Yes 

© No 



If Yes, identify the product if known and indicate the date or planned date of sale, announcements, or 
proposal and to whom the sale, announcement or proposal has been or will be made. 

Product: 
Version/Release: 
Code Name: 
Date: 
To Whom: 

f more tha 3, use out and p i 1 - 1 1 1 ' t =1 - r - i d 



|*Question4 ^ Yes 

jjWas the subject matter of your invention or a product incorporating your invention used in ™ No 
1 public, e.g., outside IBM or in the presence of non-IBMers? 



[It yes, give a date. Please format the date as MM/DD/YYYY 



Question 5 

lave you ever discu \ r i r th oth nc 1 d A I 1 [ 1 



If yes, identify individuals and, date discussed. Fill in the text area with the following information, the 
names of the individuals, the employer, date discussed, under CDA, and CDA #. 
The code for the Tax Location Derivation program was written by Dilip Patei who was employed as a contractor for IBM until 
Wh00Ht0OQk when his contract expired. Mr. Patel's contact information is listed under the 'Inventors Without Bluepages 
Entries' section of this document. He was Involved in the development of this product from4^BVWthrougtflBBSHBB 



'Question 6 


O 


Yes | 


Was the invention, in any way, started or developed under a government contract or 


© 


No 


project? 


O 


Not sure 


11 v n 3 te the < 01 ti id numbe 



Page 3 IBM Confidential Printed'WHBBRl at 09:28:58 AM 



RSW8-2001-01 63 Tax Location Derivation Process - continued 



Question 7 

Was the invention made in the course of any alliance, joint development or other contract 
activities? 

I: Yes. enter the f-:l.:.v ng: 



"Uybb" 
© No 

O Not Si 



Name of Alliance, Contractor or Joint Developer 





Contract ID number 






Rel ii tn| i nta-:' na is 




Relationship contact E-mail 


Relationship contact phone 



} Question 8 

I Have you, or any of the other inventors, submitted this same invention disclosure or similar 
in 3nt n Ji : sui r i u I ^ 



© No 



| If Yes, please provide disclosure number below: 



Question 9 

Are you, or any of the other inventors, aware of any related inventions disclosures 
submitted by anyone in. IBM previously? 



if Yes, please provide the docket or disclosure number or any other identifying information below: 



Question 10 

What type of companies do you expect to compete with inventions of this type? Check all that apply. 
Kl Manufacturers of enterprise servers 

Manufacturers of entry servers ^ 
L-o3 Manufacturers of workstations 
Kl Manufacturers of PC's 
^ Non-computer manufacturers 
K) Developers of operating systems 

Developers of networking software 
Kl Developers of application software 
Kl Integrated solution providers 

Service providers 
□ Other (Please specify below) 



Question 11 j 

| If the invention relates to a product or service that is outside the scope of your business unit, please 
| recommend IBM business unit(s), IBM location(s) orindividual(s) within IBM that you think would provide 
la good evaluation of your invention: 

I j 

Patent Value Tool (Optional - this may be used by the inventor and attorney to assist with the evalua 

(The Patent Value tool can be used by the inventor(s) to determine the potential licensing value of your 
invention.) 
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No PVT score has been calculated. To calculate a PVT score, press the 'Calculate' button. 



Market 

What is the anticipated annual market size (in dollars) that will be captured by your invention? 



CLAIMS 

Question 1 - How new is the technical field? 

Question 2 - How central is the invention to the product(s) which might be expected to contain the 
invention? 

Question 3 - What is the scope of the claim? 
PORTFOLIO NEED 

What are the portfolio needs in the area of your invention? 
EXPLOITATION & ENFORCEMENT 

Question 1 - How easily can the use of the invention by a competitor be detected? 
Question 2 - How easily can the use of the invention be avoided by a competitor? 

BUSINESS VALUE 

Question 1 - What percentage of the companies producing products in the field of this invention might use 
this invention? 

Question 2 - What is the value of this patent to current or anticipated Alliance Activity between IBM and 
other companies? 

Question 3 - What is the value of this patent to current or anticipated Technology Transfer Activity 
between IBM and other companies? 

Question 4 - Does it result in prestige to IBM? 
Post Disclosure Text & Drawings 

Enter any additional information relating to this disclosure below: 



(Form Revised 12/17/97) 
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